[Kimchi-devel] Fwd: Proposal for moving functionality from Kimchi to Ginger

Walter Niklaus niklaus at linux.vnet.ibm.com
Fri Aug 7 14:35:11 UTC 2015



On 07.08.2015 16: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.
>>

Administration isn't really specific about being host management. I 
guess the only aspect matching this description may be User Management 
and all these aspects we are discussing are Host related.

>> 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.
>>
Can we document this ? And we are talking about a new release, based on 
a new UI-Design.
Otherwise we would have to stick to current UI design and layout 
forever.  Applying design thinking may introduce some additional changes 
but I feel as long as we are doing a good job in providing an intuitive 
UI, the user will adapt very easy.


>> 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.
>>
I would hope that with the new UI design, this restriction isn't there 
anymore. Of course we have to look at the effort.
But I would like to exploit this feature in other situations as well 
since I'm planning to have the IO-management for System z as a separate 
plugin.

>>>
>>>
>>>
>>> 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20150807/b2fb6842/attachment.html>


More information about the Kimchi-devel mailing list