<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Cantarell">Hi,<br>
<br>
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.<br>
<br>
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.<br>
<br>
<b>Plugin ginger-basic:</b><br>
Base Information<br>
Basic Info<br>
Host Stats<br>
Debug Reports<br>
<br>
<b>Plugin ginger :</b><br>
System<br>
Software Update<br>
Repositories<br>
Restart, Shutdown of Host<br>
Hot-plug<br>
Networks<br>
Storage<br>
Security<br>
Firewalls<br>
SELinux<br>
PAM Config<br>
Configuration<br>
Dumps<br>
Backups<br>
Systemd<br>
...<br>
Console<br>
Users and Groups<br>
<br>
<b>Plugin ginger-ppc :</b><br>
Firmware Updates<br>
IBM SEP<br>
Energy Management<br>
<br>
<b>Plugin ginger-s390x :</b><br>
HPM<br>
Performance Metrics and Diagnostics<br>
zIO Management<br>
<br>
</font><font face="Cantarell"><font face="Cantarell">**<b>Note</b> :
Hot-plug, Security, dumps and systemd configurations etc will
be kind of future functionality that can be part of base ginger
plugin.<br>
<br>
</font><b>Key points to consider:</b><br>
1. At the moment separation of the ginger-ppc part of
functionality (mentioned above) from the ginger may not be the
highest priority. <br>
2. Shall we keep Users and Groups part of ginger plugin or do we
want this be part of base WOK frame work ?</font><br>
<br>
<font face="Cantarell"></font><font face="Cantarell">Let me know
what do you think about this !!!<br>
<br>
Regards<br>
Chandra</font><br>
<div class="moz-cite-prefix">On 08/07/2015 09:51 PM, Daniel Henrique
Barboza wrote:<br>
</div>
<blockquote cite="mid:55C4DAF6.40008@gmail.com" type="cite"> <br>
<br>
On 08/07/2015 01:14 PM, Walter Niklaus wrote: <br>
<blockquote type="cite"> <br>
<br>
On 07.08.2015 18:05, Aline Manera wrote: <br>
<blockquote type="cite"> <br>
Seems we are close to a conclusion on that subject. ;-) <br>
<br>
Let me resume what we have already agreed: <br>
<br>
1) Move software update + repositories + restart + shutdown +
console to Ginger <br>
<br>
2) Create a new plugin for host basic info + host stats +
debug reports <br>
<br>
My proposal is to have this new plugin under Ginger community
responsibility. <br>
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. <br>
<br>
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. <br>
And 'ginger' plugin will extend this Host tab generated by
ginger-basic. <br>
<br>
It will increase the Ginger community scope and make everyone
happy! =) <br>
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) <br>
<br>
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. <br>
In a simple phrase, Ginger plugins provide a Host tab based on
wok framework. <br>
<br>
To do not get the user crazy "Where is Ginger now?" while
loading the updated version, I have 2 suggestion: <br>
<br>
A) Work with plugin logos! <br>
Maybe a pan design to represent wok framework and on top
of it all the plugins logos are displayed. <br>
To do that we will need a logo for wok and ginger. <br>
<br>
B) Create a introduction page to show the differences from the
older version. <br>
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"... <br>
<br>
</blockquote>
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 :-) <br>
<br>
<blockquote type="cite">Do you agree, Daniel and Walter? <br>
<br>
</blockquote>
I agree. <br>
</blockquote>
<br>
I agree. Unless someone else has a strong point against it, we can
move forward with this idea, <br>
starting discussions about what needs to be done and how long
we'll need to make it happen. From <br>
the top of my head the most critical point is how to make the
current engine support a plug-in <br>
extends an existing plug-in. We can start there. <br>
<br>
<blockquote type="cite"> <br>
<blockquote type="cite">Regards, <br>
Aline Manera <br>
</blockquote>
<br>
</blockquote>
<br>
_______________________________________________ <br>
Kimchi-devel mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<br>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>