Am 10.08.2015 um 19:44 schrieb Daniel Henrique Barboza:
Makes sense, we should try to make this one platform independent. I guess we are not there yet, but we should plan for.
On 08/10/2015 02:31 PM, Chandra Shehkhar Reddy Potula chandra@linux.vnet.ibm.com [ginger-dev] wrote:
Hi,Energy management isn't exclusive to Power. It works in x86_64 too.
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
This feature can be multi-architecture if the tools used to get the metrics/diagnostics aren't
exclusive to Z.
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.
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.
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.
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.
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:
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 :-)
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?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