[Kimchi-devel] Fwd: Proposal for moving functionality from Kimchi to Ginger
Aline Manera
alinefm at linux.vnet.ibm.com
Fri Aug 7 14:32:05 UTC 2015
On 07/08/2015 11:16, Daniel Henrique Barboza wrote:
>
>
> On 08/07/2015 11:12 AM, Daniel Henrique Barboza wrote:
>>
>>
>> On 08/07/2015 05:53 AM, Walter Niklaus wrote:
>>> Aline,
>>>
>>> the goal of my mail wasn't a scrum summary only, I was rather trying
>>> to get us into a design thinking mode: looking at the problem from
>>> a user point of view, what would a user expect to exploit in the
>>> various use cases. I'll keep focusing on this aspect in our future
>>> discussions :-)
>>>
>>> I like your proposal from an overall point because for making
>>> progress now it is the best solution.
>>> When it comes to plugins-priority and implentation I have a simpler
>>> proposal:
>>> - Instead of this smart logic you are proposing implement the
>>> following:
>>> - whenever common-host plugin is available it will get
>>> installed and create a Host tab with the functionality 2,3 and 6
>>> - when Ginger plugin is getting installed it will simply
>>> extend the Host tab with all the other functionalties
>>
>> Why get rid of the 'Administration' tab from Ginger? We can use the
>> 'Host' tab to provide basic
>> information + debug reports and the Administration tab to manage the
>> host itself. We can even
>> rename the 'Host' tab to 'Host status' to clarify even further.
>>
>> Get rid of the Ginger tab can, and will, confuse the existing users.
>> They will install the plug-in,
>> they will not see the Administration tab and will think that Ginger
>> installation failed.
>>
Good point! From a Ginger side, I agree extending the common-host plugin
will not provide a good user experience.
So I don't see problems in having both tabs while loading Ginger for
instance: Host + Administration.
About renaming the Host tab to better clarification I suggest "Host details"
>> Besides that, the current engine does not support a plug-in that
>> extends an existing tab from
>> another plug-in. I have no idea of the amount of work this can take.
>>
>>>
>>>
>>>
>>> On 06.08.2015 17:11, Aline Manera wrote:
>>>>
>>>> Thanks, Walter, to send the scrum meeting summary here!
>>>>
>>>> Here are my thoughts on all that.
>>>>
>>>> First, let me clarify the proposal of each piece of cake! =)
>>>>
>>>> A) Wok is a *generic web server framework based on plugins*.
>>>> By generic, I mean it should only expose APIs and
>>>> functionalities required for a web server. Login, logout, plugins
>>>> support, i18n support, message error handling and much more.
>>>>
>>>> B) Kimchi is a wok plugin for virtual machine management.
>>>> And it is independent system platform: x86, Power or Z.
>>>>
>>>> C) Ginger is a wok plugin for host management.
>>>> And it is independent system platform: x86, Power or Z.
>>>>
>>>> By now, it is all we have. So I'd like to concentrate our effort on it.
>>>>
>>>> Now thinking about which features from Kimchi Host tab can be moved
>>>> to Ginger.
>>>> Let do it item by item. The Host Tab is composed by:
>>>>
>>>> 1) Restart, Shutdown, Connect operations
>>>> I don't see those functionalities close related to virtual
>>>> machines management. So for me, it is fine and good to move them to
>>>> Ginger.
>>>>
>>>> 2) Basic Information
>>>> The kind of information may be very useful to user while manage
>>>> virtual machine. Specially by the amount of memory and number of CPUs.
>>>> With that information the user can properly balance his/her
>>>> virtual machines configuration to have better system performance.
>>>>
>>>> 3) Host statistics
>>>> The same I described on item 2.
>>>>
>>>> 4) Software Update
>>>> I don't see this functionality close related to virtual
>>>> machines management. So for me, it is fine and good to move them to
>>>> Ginger.
>>>>
>>>> 5) Repository management
>>>> I don't see this functionality close related to virtual
>>>> machines management. So for me, it is fine and good to move them to
>>>> Ginger.
>>>>
>>>> 6) Debug reports
>>>> This functionality may be interesting for virtual machine
>>>> management when some of them represents a problem or bad performance.
>>>> So user can easily grab the system logs to check what is going
>>>> wrong.
>>>>
>>>> So if no one opposes, we can start moving 1, 4 and 5 to Ginger.
>>>> As we have 2 different open source communities we need to
>>>> coordinate that work. Initially the patch for Kimchi will be for
>>>> removing those features and to Ginger to add them.
>>>> The Kimchi patch must be simpler but it will require more work on
>>>> Ginger side.
>>>>
>>>> About 2, 3 and 6: I really understand how those information are
>>>> important for virtual machine management and also for host
>>>> management, i.e, Kimchi and Ginger.
>>>> (And I hope you all do the same :-) )
>>>>
>>>> So in my mind, we are discussing a solution to expose those
>>>> information on both, Kimchi and Ginger, without making it
>>>> duplicated somehow to user.
>>>>
>>>> As per discussion (see item A), wok is a generic framework and
>>>> should not handle those kind of APIs. (Agree?)
>>>> And also it should not have any default plugin (otherwise, we could
>>>> continue having Kimchi as default without the need to have the wok
>>>> framework)
>>>> While loading wok without any plugin, it should display a simple
>>>> page "Welcome to wok" or something like that but without any
>>>> functionality.
>>>>
>>>> So my proposal is to create a new and simple plugin (let's call it
>>>> as common-host plugin) that expose those APIs without any UI.
>>>>
>>>> Kimchi and Ginger will have a dependency on this common-host plugin
>>>> and will provide the proper UI for it.
>>>>
>>>> To do not duplicate information while loading Kimchi and Ginger
>>>> together, I propose to add a smart logic for it:
>>>>
>>>> - Kimchi will always load the Host tab with the common-host plugin
>>>> (as it is today).
>>>> - Ginger will load the common-host plugin *only and if only* it is
>>>> running standalone.
>>>>
>>>> What do you think about it?
>>>>
>>>> Regards,
>>>> Aline Manera
>>>>
>>>> On 06/08/2015 11:15, Walter Niklaus wrote:
>>>>> 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 at ovirt.org
>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Kimchi-devel mailing list
>>>>>>>>> Kimchi-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kimchi-devel mailing list
>>>>> Kimchi-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20150807/8f591346/attachment.html>
More information about the Kimchi-devel
mailing list