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

[Chandra Shehkhar Reddy Potula]

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 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/20150810/e9e3bdd7/attachment.html>