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@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> >> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/08/2015 11: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.
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.
Good point! From a Ginger side, I agree extending the common-host plugin will not provide a good user experience. So I don't see problems in having both tabs while loading Ginger for instance: Host + Administration. About renaming the Host tab to better clarification I suggest "Host details"
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@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >>> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >>> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> >
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Seems we are close to a conclusion on that subject. ;-) Let me resume what we have already agreed: 1) Move software update + repositories + restart + shutdown + console to Ginger 2) Create a new plugin for host basic info + host stats + debug reports My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me. Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic. It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community) So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework. To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion: A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger. B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"... Do you agree, Daniel and Walter? Regards, Aline Manera
On 07.08.2015 18:05, Aline Manera wrote:
Seems we are close to a conclusion on that subject. ;-)
Let me resume what we have already agreed:
1) Move software update + repositories + restart + shutdown + console to Ginger
2) Create a new plugin for host basic info + host stats + debug reports
My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me.
Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic.
It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community)
So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework.
To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion:
A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger.
B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"...
I'm ok with both solutions although since we are planning to redesign the UI in order to improve the user experience I hope that we are able to do a very good job and make the new UI-design intuitive enough for the user to find the right menue points :-)
Do you agree, Daniel and Walter?
I agree.
Regards, Aline Manera
On 08/07/2015 01:14 PM, Walter Niklaus wrote:
On 07.08.2015 18:05, Aline Manera wrote:
Seems we are close to a conclusion on that subject. ;-)
Let me resume what we have already agreed:
1) Move software update + repositories + restart + shutdown + console to Ginger
2) Create a new plugin for host basic info + host stats + debug reports
My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me.
Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic.
It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community)
So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework.
To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion:
A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger.
B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"...
I'm ok with both solutions although since we are planning to redesign the UI in order to improve the user experience I hope that we are able to do a very good job and make the new UI-design intuitive enough for the user to find the right menue points :-)
Do you agree, Daniel and Walter?
I agree.
I agree. Unless someone else has a strong point against it, we can move forward with this idea, starting discussions about what needs to be done and how long we'll need to make it happen. From the top of my head the most critical point is how to make the current engine support a plug-in extends an existing plug-in. We can start there.
Regards, Aline Manera
Hi, It is good idea to modularize the host functionality as plugins. Keeping common host functionality as a one plugin and at the same time having platform specific host functionality as additional plugins gives choice of picking up the relevant features on specific platform. Since we had an agreement on the movement of host functionality from kimchi to ginger, here is draft proposal I have to modularize the ginger functionality. *Plugin ginger-basic:* Base Information Basic Info Host Stats Debug Reports *Plugin ginger :* System Software Update Repositories Restart, Shutdown of Host Hot-plug Networks Storage Security Firewalls SELinux PAM Config Configuration Dumps Backups Systemd ... Console Users and Groups *Plugin ginger-ppc :* Firmware Updates IBM SEP Energy Management *Plugin ginger-s390x :* HPM Performance Metrics and Diagnostics zIO Management ***Note* : Hot-plug, Security, dumps and systemd configurations etc will be kind of future functionality that can be part of base ginger plugin. *Key points to consider:* 1. At the moment separation of the ginger-ppc part of functionality (mentioned above) from the ginger may not be the highest priority. 2. Shall we keep Users and Groups part of ginger plugin or do we want this be part of base WOK frame work ? Let me know what do you think about this !!! Regards Chandra On 08/07/2015 09:51 PM, Daniel Henrique Barboza wrote:
On 08/07/2015 01:14 PM, Walter Niklaus wrote:
On 07.08.2015 18:05, Aline Manera wrote:
Seems we are close to a conclusion on that subject. ;-)
Let me resume what we have already agreed:
1) Move software update + repositories + restart + shutdown + console to Ginger
2) Create a new plugin for host basic info + host stats + debug reports
My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me.
Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic.
It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community)
So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework.
To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion:
A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger.
B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"...
I'm ok with both solutions although since we are planning to redesign the UI in order to improve the user experience I hope that we are able to do a very good job and make the new UI-design intuitive enough for the user to find the right menue points :-)
Do you agree, Daniel and Walter?
I agree.
I agree. Unless someone else has a strong point against it, we can move forward with this idea, starting discussions about what needs to be done and how long we'll need to make it happen. From the top of my head the most critical point is how to make the current engine support a plug-in extends an existing plug-in. We can start there.
Regards, Aline Manera
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 08/10/2015 02:31 PM, Chandra Shehkhar Reddy Potula chandra@linux.vnet.ibm.com [ginger-dev] wrote:
Hi,
It is good idea to modularize the host functionality as plugins. Keeping common host functionality as a one plugin and at the same time having platform specific host functionality as additional plugins gives choice of picking up the relevant features on specific platform.
Since we had an agreement on the movement of host functionality from kimchi to ginger, here is draft proposal I have to modularize the ginger functionality.
*Plugin ginger-basic:* Base Information Basic Info Host Stats Debug Reports
*Plugin ginger :* System Software Update Repositories Restart, Shutdown of Host Hot-plug Networks Storage Security Firewalls SELinux PAM Config Configuration Dumps Backups Systemd ... Console Users and Groups
*Plugin ginger-ppc :* Firmware Updates IBM SEP Energy Management Energy management isn't exclusive to Power. It works in x86_64 too.
*Plugin ginger-s390x :* HPM Performance Metrics and Diagnostics
This feature can be multi-architecture if the tools used to get the metrics/diagnostics aren't exclusive to Z.
zIO Management
***Note* : Hot-plug, Security, dumps and systemd configurations etc will be kind of future functionality that can be part of base ginger plugin.
*Key points to consider:* 1. At the moment separation of the ginger-ppc part of functionality (mentioned above) from the ginger may not be the highest priority. 2. Shall we keep Users and Groups part of ginger plugin or do we want this be part of base WOK frame work ?
The idea is to keep the WOK framework 'featureless'. It will consist only in the cherrypy server, model/control APIs and a 'Welcome to WOK' message when no plug-in is installed.
Let me know what do you think about this !!!
Just a reminder: we still need to figure it out how we'll change the current engine to support a plug-in extending an existing tab from another plug-in. And another reminder: Ginger mailing list is now ginger-dev-list@nongnu.org. Feel free to join the ML: https://lists.nongnu.org/mailman/listinfo/ginger-dev-list Daniel
Regards Chandra On 08/07/2015 09:51 PM, Daniel Henrique Barboza wrote:
On 08/07/2015 01:14 PM, Walter Niklaus wrote:
On 07.08.2015 18:05, Aline Manera wrote:
Seems we are close to a conclusion on that subject. ;-)
Let me resume what we have already agreed:
1) Move software update + repositories + restart + shutdown + console to Ginger
2) Create a new plugin for host basic info + host stats + debug reports
My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me.
Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic.
It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community)
So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework.
To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion:
A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger.
B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"...
I'm ok with both solutions although since we are planning to redesign the UI in order to improve the user experience I hope that we are able to do a very good job and make the new UI-design intuitive enough for the user to find the right menue points :-)
Do you agree, Daniel and Walter?
I agree.
I agree. Unless someone else has a strong point against it, we can move forward with this idea, starting discussions about what needs to be done and how long we'll need to make it happen. From the top of my head the most critical point is how to make the current engine support a plug-in extends an existing plug-in. We can start there.
Regards, Aline Manera
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Am 10.08.2015 um 19:44 schrieb Daniel Henrique Barboza:
On 08/10/2015 02:31 PM, Chandra Shehkhar Reddy Potula chandra@linux.vnet.ibm.com [ginger-dev] wrote:
Hi,
It is good idea to modularize the host functionality as plugins. Keeping common host functionality as a one plugin and at the same time having platform specific host functionality as additional plugins gives choice of picking up the relevant features on specific platform.
Since we had an agreement on the movement of host functionality from kimchi to ginger, here is draft proposal I have to modularize the ginger functionality.
*Plugin ginger-basic:* Base Information Basic Info Host Stats Debug Reports
*Plugin ginger :* System Software Update Repositories Restart, Shutdown of Host Hot-plug Networks Storage Security Firewalls SELinux PAM Config Configuration Dumps Backups Systemd ... Console Users and Groups
*Plugin ginger-ppc :* Firmware Updates IBM SEP Energy Management Energy management isn't exclusive to Power. It works in x86_64 too.
*Plugin ginger-s390x :* HPM Performance Metrics and Diagnostics
This feature can be multi-architecture if the tools used to get the metrics/diagnostics aren't exclusive to Z.
Makes sense, we should try to make this one platform independent. I guess we are not there yet, but we should plan for.
zIO Management
***Note* : Hot-plug, Security, dumps and systemd configurations etc will be kind of future functionality that can be part of base ginger plugin.
*Key points to consider:* 1. At the moment separation of the ginger-ppc part of functionality (mentioned above) from the ginger may not be the highest priority. 2. Shall we keep Users and Groups part of ginger plugin or do we want this be part of base WOK frame work ?
The idea is to keep the WOK framework 'featureless'. It will consist only in the cherrypy server, model/control APIs and a 'Welcome to WOK' message when no plug-in is installed.
Keeping wok featurelss makes lot of sense. I guess what we need to think about is the scope of user and roles management. From what I currently see there are currently 3 roles/profiles defined: Administrator, Kimchi User and Virt User. With the agreed feature split User Management is available only if Ginger is installed, which is true with the current stable implementation as well. Since in the current implementation Kimchi is always available we don't have an issue offering Kimchi and Virt User profiles by default, but after the separation these profiles make sense only if Kimchi plugin is installed. Theoretically any new plugin could bring in the requirement of new profiles. The other question we have to clarify is: do we need User Management when Ginger is not available as plugin ? From the implementation I understand that we are talking here only about locally (on this host) defined users and roles, ldap user management isn't performed. From this point of view it's fitting in the scope of Host Management. The part not really fitting is the plugin specific profile aspect. Since we want to keep the plugins as independent as possible from each other, one option I see is: if a certain plugin has the requirement for a certain user role it has to expose the description of this role in a tbd. format to the User Management feature.
Let me know what do you think about this !!!
Just a reminder: we still need to figure it out how we'll change the current engine to support a plug-in extending an existing tab from another plug-in. We are working on that one. If it proofs to be too much of work or uggly hack, I would propose to leave it how it is for now in the old UI-design (meaning keep Administration tab) and do the final UI-restructuring based on the new UI-Design.
And another reminder: Ginger mailing list is now ginger-dev-list@nongnu.org. Feel free to join the ML:
https://lists.nongnu.org/mailman/listinfo/ginger-dev-list
Daniel
Regards Chandra On 08/07/2015 09:51 PM, Daniel Henrique Barboza wrote:
On 08/07/2015 01:14 PM, Walter Niklaus wrote:
On 07.08.2015 18:05, Aline Manera wrote:
Seems we are close to a conclusion on that subject. ;-)
Let me resume what we have already agreed:
1) Move software update + repositories + restart + shutdown + console to Ginger
2) Create a new plugin for host basic info + host stats + debug reports
My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me.
Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic.
It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community)
So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework.
To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion:
A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger.
B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"...
I'm ok with both solutions although since we are planning to redesign the UI in order to improve the user experience I hope that we are able to do a very good job and make the new UI-design intuitive enough for the user to find the right menue points :-)
Do you agree, Daniel and Walter?
I agree.
I agree. Unless someone else has a strong point against it, we can move forward with this idea, starting discussions about what needs to be done and how long we'll need to make it happen. From the top of my head the most critical point is how to make the current engine support a plug-in extends an existing plug-in. We can start there.
Regards, Aline Manera
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 11/08/2015 10:06, Walter Niklaus wrote:
Am 10.08.2015 um 19:44 schrieb Daniel Henrique Barboza:
On 08/10/2015 02:31 PM, Chandra Shehkhar Reddy Potula chandra@linux.vnet.ibm.com [ginger-dev] wrote:
Hi,
It is good idea to modularize the host functionality as plugins. Keeping common host functionality as a one plugin and at the same time having platform specific host functionality as additional plugins gives choice of picking up the relevant features on specific platform.
Since we had an agreement on the movement of host functionality from kimchi to ginger, here is draft proposal I have to modularize the ginger functionality.
*Plugin ginger-basic:* Base Information Basic Info Host Stats Debug Reports
*Plugin ginger :* System Software Update Repositories Restart, Shutdown of Host Hot-plug Networks Storage Security Firewalls SELinux PAM Config Configuration Dumps Backups Systemd ... Console Users and Groups
*Plugin ginger-ppc :* Firmware Updates IBM SEP Energy Management Energy management isn't exclusive to Power. It works in x86_64 too.
*Plugin ginger-s390x :* HPM Performance Metrics and Diagnostics
This feature can be multi-architecture if the tools used to get the metrics/diagnostics aren't exclusive to Z.
Makes sense, we should try to make this one platform independent. I guess we are not there yet, but we should plan for.
zIO Management
***Note* : Hot-plug, Security, dumps and systemd configurations etc will be kind of future functionality that can be part of base ginger plugin.
*Key points to consider:* 1. At the moment separation of the ginger-ppc part of functionality (mentioned above) from the ginger may not be the highest priority. 2. Shall we keep Users and Groups part of ginger plugin or do we want this be part of base WOK frame work ?
The idea is to keep the WOK framework 'featureless'. It will consist only in the cherrypy server, model/control APIs and a 'Welcome to WOK' message when no plug-in is installed.
Keeping wok featurelss makes lot of sense. I guess what we need to think about is the scope of user and roles management. From what I currently see there are currently 3 roles/profiles defined: Administrator, Kimchi User and Virt User. With the agreed feature split User Management is available only if Ginger is installed, which is true with the current stable implementation as well. Since in the current implementation Kimchi is always available we don't have an issue offering Kimchi and Virt User profiles by default, but after the separation these profiles make sense only if Kimchi plugin is installed. Theoretically any new plugin could bring in the requirement of new profiles. The other question we have to clarify is: do we need User Management when Ginger is not available as plugin ? From the implementation I understand that we are talking here only about locally (on this host) defined users and roles, ldap user management isn't performed. From this point of view it's fitting in the scope of Host Management. The part not really fitting is the plugin specific profile aspect. Since we want to keep the plugins as independent as possible from each other, one option I see is: if a certain plugin has the requirement for a certain user role it has to expose the description of this role in a tbd. format to the User Management feature.
In the current wok implementation we have 2 types of users: admin and user. Each plugin specify the user access by the config/ui/tabs.xml file. The profiles associated to a user through the users and groups management provided by Ginger there is nothing related to the authorization settings - at least by now. (And AFAIK, there is no plan to associate them.) If it is the new focus of this conversation, I suggest to create a new email thread with a well documented proposal for wok and its plugins.
Let me know what do you think about this !!!
Just a reminder: we still need to figure it out how we'll change the current engine to support a plug-in extending an existing tab from another plug-in. We are working on that one. If it proofs to be too much of work or uggly hack, I would propose to leave it how it is for now in the old UI-design (meaning keep Administration tab) and do the final UI-restructuring based on the new UI-Design.
And another reminder: Ginger mailing list is now ginger-dev-list@nongnu.org. Feel free to join the ML:
https://lists.nongnu.org/mailman/listinfo/ginger-dev-list
Daniel
Regards Chandra On 08/07/2015 09:51 PM, Daniel Henrique Barboza wrote:
On 08/07/2015 01:14 PM, Walter Niklaus wrote:
On 07.08.2015 18:05, Aline Manera wrote:
Seems we are close to a conclusion on that subject. ;-)
Let me resume what we have already agreed:
1) Move software update + repositories + restart + shutdown + console to Ginger
2) Create a new plugin for host basic info + host stats + debug reports
My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me.
Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic.
It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community)
So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework.
To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion:
A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger.
B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"...
I'm ok with both solutions although since we are planning to redesign the UI in order to improve the user experience I hope that we are able to do a very good job and make the new UI-design intuitive enough for the user to find the right menue points :-)
Do you agree, Daniel and Walter?
I agree.
I agree. Unless someone else has a strong point against it, we can move forward with this idea, starting discussions about what needs to be done and how long we'll need to make it happen. From the top of my head the most critical point is how to make the current engine support a plug-in extends an existing plug-in. We can start there.
Regards, Aline Manera
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 10/08/2015 14:31, Chandra Shehkhar Reddy Potula wrote:
Hi,
It is good idea to modularize the host functionality as plugins. Keeping common host functionality as a one plugin and at the same time having platform specific host functionality as additional plugins gives choice of picking up the relevant features on specific platform.
Since we had an agreement on the movement of host functionality from kimchi to ginger, here is draft proposal I have to modularize the ginger functionality.
As Daniel said we should do this discussion on Ginger community as it is not related to Kimchi. Please, join the Ginger mailing list: https://lists.nongnu.org/mailman/listinfo/ginger-dev-list
*Plugin ginger-basic:* Base Information Basic Info Host Stats Debug Reports
*Plugin ginger :* System Software Update Repositories Restart, Shutdown of Host Hot-plug Networks Storage Security Firewalls SELinux PAM Config Configuration Dumps Backups Systemd ... Console Users and Groups
*Plugin ginger-ppc :* Firmware Updates IBM SEP Energy Management
*Plugin ginger-s390x :* HPM Performance Metrics and Diagnostics zIO Management
***Note* : Hot-plug, Security, dumps and systemd configurations etc will be kind of future functionality that can be part of base ginger plugin.
*Key points to consider:* 1. At the moment separation of the ginger-ppc part of functionality (mentioned above) from the ginger may not be the highest priority. 2. Shall we keep Users and Groups part of ginger plugin or do we want this be part of base WOK frame work ?
wok is a web server framework based on plugins so only features related to web server and configuration should be there.
Let me know what do you think about this !!!
Regards Chandra On 08/07/2015 09:51 PM, Daniel Henrique Barboza wrote:
On 08/07/2015 01:14 PM, Walter Niklaus wrote:
On 07.08.2015 18:05, Aline Manera wrote:
Seems we are close to a conclusion on that subject. ;-)
Let me resume what we have already agreed:
1) Move software update + repositories + restart + shutdown + console to Ginger
2) Create a new plugin for host basic info + host stats + debug reports
My proposal is to have this new plugin under Ginger community responsibility. AFAIU, the Ginger community is for a host management plugin. And as this new plugin is for basic host details, it makes all sense for me.
Thinking on that, I suggest to name this new plugin as 'ginger-basic' which will load a tab named 'Host' with host basic information + host stats + debug reports. And 'ginger' plugin will extend this Host tab generated by ginger-basic.
It will increase the Ginger community scope and make everyone happy! =) We can also think about splitting ginger into: ginger, ginger-ppc, ginger-z, etc... (but it is an other different topic to be discussed on Ginger community)
So from a user and devel perspective, the whole Kimchi Host tab will be moved to Ginger community into 2 different plugins: ginger-basic and ginger. In a simple phrase, Ginger plugins provide a Host tab based on wok framework.
To do not get the user crazy "Where is Ginger now?" while loading the updated version, I have 2 suggestion:
A) Work with plugin logos! Maybe a pan design to represent wok framework and on top of it all the plugins logos are displayed. To do that we will need a logo for wok and ginger.
B) Create a introduction page to show the differences from the older version. The idea behind it is like some Android applications do when get updated. Once you open it, a page is displayed as a layer on top of the application with balloons and arrows to tell "this feature was moved to here"...
I'm ok with both solutions although since we are planning to redesign the UI in order to improve the user experience I hope that we are able to do a very good job and make the new UI-design intuitive enough for the user to find the right menue points :-)
Do you agree, Daniel and Walter?
I agree.
I agree. Unless someone else has a strong point against it, we can move forward with this idea, starting discussions about what needs to be done and how long we'll need to make it happen. From the top of my head the most critical point is how to make the current engine support a plug-in extends an existing plug-in. We can start there.
Regards, Aline Manera
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (4)
-
Aline Manera -
Chandra Shehkhar Reddy Potula -
Daniel Henrique Barboza -
Walter Niklaus