Picking up the discussion from the Scrum meeting about where
(which plugin) certain functionalities should be.
To make sure we don't miss this aspect, I'm re-iterating on
the high level use cases.
Currently I see the following major usecases now and in the
near future (next year):
1. A user wants to perform base Linux management only.
- here he needs all the generic Host-Management
functionality + the platform specific stuff like:
Power-FW code update, Energy Management on Power or
IO-Device Management on System z
2. A user wants to manage KVM Virtual Machines.
- his primary scope are VMs. How much of the Host and
Platform specific Management functionality is required here ?
3. A user wants to manage Containers.
- his primary scope are Container. How much of the Host
and Platform specific Management functionality is required
here ?
4. A user wants to manage Containers and KVM Virtual
Machines .
- his primary scope are Container and VMs. How much of
the Host and Platform specific Management functionality is
required here ?
Our current discussion now is for the usecases 2,3 and 4: How
much of the Host and Platform specific Management
functionality is required and what's the best way to organize
and package it.
One possibility could be to have all Host-Management
functionality looked at being part of the default/basic
functionset and delivery and have the Platform specifc
functionality as optional plugins. The disadvantage of this
approach would be that all the following functionality:
Basic Information, System Statistics, Network (Host NICs,DNS
...), Storage/SAN (Host Storage), User Management,
Configuration Backup, Software Updates, Repositories, Debug
Reports would be present in the Container and VM usecases by
default.
Do we know what a user really needs and wants in the usecases
2,3 and 4 ? I guess this depends to a large degree of the
toolset she/he is using beside Kimchi and Ginger. If there is
no other tooling available she/he may be happy about the
shipped functionset, but for sure there are other situation
where she/he may not be interested in some of the
functionality.
What could be the reasons a user would want to pick
selectively ?
a. functionality not required or maybe even conflicting
with some other tooling: for example Software Updates
are managed from some central instance
b. installing a reduced functionset could reduce the
external package dependencies and could reduce the amount of
updates
c. simplification on the UI by eliminating unrequired
stuff
Ideally the user could choose on an individual functionality
base and configure the tool based on his needs.
I guess satisfying the reasons a. and c. from above could be
implemented via UI customisation even on an individual
Kimchi/Ginger user base.
Reason b. can be probably achieved only by segregating the set
of fuctionality in separate plugins.
On 04.08.2015 17:26, Walter
Niklaus wrote:
... Daniel sorry for the duplicate send, I missed to reply
to all so the mail didn't go to the mailing list.
On 04.08.2015 14:39, Daniel
Henrique Barboza wrote:
On 08/04/2015 04:56 AM,
Walter Niklaus wrote:
Hi Daniel,
sorry for missing the thread where this topic was
discussed.
I can fully understand the point about Basic Information
and System Statistics being relevant for Virtualization
management as well and I like the idea of potentially
making it part of the base framework because they would
be very usefull for other plugins, like
Container-Management as well.
The interesting question is then if some of the other
functions wouldn't make sense to be part of the basic
framework as well. Debug reports would be a classical
candidate from my point of view, but wouldn't some of
the other functions be usefull in the base as well ?
If we're really going in that approach (putting basic
features in WoK), I agree. We would have to
discuss each existing feature and evaluate if it belongs
to kimchi, ginger or wok.
I guess we really need to have a discussion on the
individual features but I would like to start this one from
a user requirements point of view.
Currently I see the following major usecases now and in the
near feature:
1. A user wants to perform base Linux management only.
2. A user wants to manage KVM Virtual Machines.
3. A user wants to manage Containers.
4. A user wants to manage Containers and KVM Virtual
Machines .
For the usecases 2, 3 and 4 the user needs usecase 1 as well
in order to prepare and manage the Host machine.
I'm not proposing to make the Linux Host Management part of
the base framework because we just separated out Kimchi of
it, but I think it makes a lot of sense to deliver the Host
Management plugin by default with the base framework.
Looking at the problem form a different angle: wouldn't
it make sense to package and deliver the base framework
with the Ginger plugin by default because the
Host-functionality Ginger is offering would be usefull
for the other plugins like Virtualization and Containers
?
What I missed in my previous mail is the aspect about
platform specific functionality. This functionality,
like PPC firmware update or IO-device management for
Linux on z should be made available as individual
plugins.
At this moment Ginger can handle multi-arch features
fairly well. For example, Firmware
Update does not appear when running the plug-in in an
Intel computer. The feature you mentioned,
IO-device management for Linux on Z, would be available
only when running Ginger in a Linux
for Z host.
There's absolutely nothing holding you from making a brand
new plug-in for the Z features instead
of adding them to Ginger, but it is important to know that
Ginger is designed for these scenarios.
You can even create a new UI tab in Ginger, something like
'Z management' which would contain all Z related features.
This tab would only appear in a Linux on Z host. From the
UI perspective it looks
like a brand new plug-in working together with Ginger
common features in the 'Administration' tab.
Please let me know what you think about this option.
Thanks,
Walter.
On 03.08.2015 18:51, Daniel
Henrique Barboza wrote:
Hi Walter,
We've had this discussion with the community a few
months ago in the thread
"[RFC] Moving some features of Host tab to Ginger"
And we agreed to start it by moving only Software
Update, Repositories and
Debug Reports from Kimchi to Ginger.
The Basic Information and System Statistics can't be
taken away from Kimchi because there
are relevant information for the creation of VMs
there, such as Memory Available. But I agree
that these information fits nicely in Ginger too.
One alternative (just came in my head now) is to move
these "neutral" functions
to a "Basic System Info" in WoK. That way both Kimchi
and Ginger users can access
the information.
Thanks,
Daniel
On 08/03/2015 12:15 PM,
Walter Niklaus wrote:
After separating out Kimchi as an indvidual plugin
from the base
framework it would be great to have a clean
separation between Host- and
Virtualization Management functions. I'm planning to
work on this topic
in the next few weeks and have prepared a proposal
of the functionsplit.
Plugin functionality:
- Ginger:
- Basic Information
- System Statistics
- Network (Host NICs)
- Storage/SAN (Host Storage)
- User Management
- Configuration Backup
- Software Updates
- Repositories
- Debug Reports
- PPC related functions: Firmware Update
& Power Management
- Kimchi:
- Templates
- Guests
- Networks (virtual)
- Storage (Pools for VMs)
Since there are plans to restructure the UI for one
of the next
releases, I'm proposing to do only some minimal
investments in
reflecting this new finctionsplit. Therefore I'm
proposing to make the
Host tab as the one and only Tab for Ginger and move
everything from the
Administration Tab into the Host Tab. This would be
just an
intermediate solution till we implement the new UI
design. Please see
the attached PDF.
Thanks in advance for your feedback.
Walter.
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel