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

Tue Aug 11 13:57:57 UTC 2015

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20150811/470b2e46/attachment.html>