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

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(a)ovirt.org >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Kimchi-devel mailing list >>>>>>>> Kimchi-devel(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Kimchi-devel mailing list >>>> Kimchi-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >> >> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >