[Kimchi-devel] Fwd: Proposal for moving functionality from Kimchi to Ginger
Aline Manera
alinefm at linux.vnet.ibm.com
Fri Aug 7 13:49:02 UTC 2015
On 07/08/2015 05:53, 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
>
ACK.
>
>
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20150807/ddb2ca09/attachment.html>
More information about the Kimchi-devel
mailing list