[Kimchi-devel] Fwd: Proposal for moving functionality from Kimchi to Ginger
Aline Manera
alinefm at linux.vnet.ibm.com
Thu Aug 6 18:56:01 UTC 2015
On 06/08/2015 14:49, Harshal Patil wrote:
> About 2) Basic info and 3)host stats below, do you think wok should
> actually display that info in tab or should it be just available only
> through API so that plugin developers can decide to display it in
> whichever way they prefer?
I have thought about it initially, but I don't agree any more as it
would break the idea of having on wok only what is needed to provide a
web server based on plugins.
Because that I proposed the common-host plugin to expose the APIs.
> ----- Original message -----
> From: Aline Manera <alinefm at linux.vnet.ibm.com>
> Sent by: kimchi-devel-bounces at ovirt.org
> To: Walter Niklaus <niklaus at linux.vnet.ibm.com>, Daniel Henrique
> Barboza <danielhb at linux.vnet.ibm.com>, Kimchi Devel
> <kimchi-devel at ovirt.org>
> Cc:
> Subject: Re: [Kimchi-devel] Fwd: Proposal for moving functionality
> from Kimchi to Ginger
> Date: Thu, Aug 6, 2015 9:01 PM
>
>
> 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 <mailto:Kimchi-devel at ovirt.org>
>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kimchi-devel mailing list
>>>>>> Kimchi-devel at ovirt.org <mailto:Kimchi-devel at ovirt.org>
>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org <mailto: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/20150806/33efa5a5/attachment.html>
More information about the Kimchi-devel
mailing list