[Kimchi-devel] Fwd: Proposal for moving functionality from Kimchi to Ginger
Daniel Henrique Barboza
dhbarboza82 at gmail.com
Fri Aug 7 14:16:11 UTC 2015
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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20150807/d6fb99d9/attachment.html>
More information about the Kimchi-devel
mailing list