<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 07/08/2015 11:16, Daniel Henrique
Barboza wrote:<br>
</div>
<blockquote cite="mid:55C4BDAB.4050205@gmail.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 08/07/2015 11:12 AM, Daniel
Henrique Barboza wrote:<br>
</div>
<blockquote cite="mid:55C4BCE9.1070700@gmail.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 08/07/2015 05:53 AM, Walter
Niklaus wrote:<br>
</div>
<blockquote cite="mid:55C471FB.1060004@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Aline,<br>
<br>
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 :-)<br>
<br>
I like your proposal from an overall point because for making
progress now it is the best solution. <br>
When it comes to plugins-priority and implentation I have a
simpler proposal:<br>
- Instead of this smart logic you are proposing implement
the following:<br>
- whenever common-host plugin is available it will get
installed and create a Host tab with the functionality 2,3 and
6<br>
- when Ginger plugin is getting installed it will
simply extend the Host tab with all the other functionalties <br>
</blockquote>
<br>
Why get rid of the 'Administration' tab from Ginger? We can use
the 'Host' tab to provide basic<br>
information + debug reports and the Administration tab to manage
the host itself. We can even<br>
rename the 'Host' tab to 'Host status' to clarify even further.<br>
<br>
Get rid of the Ginger tab can, and will, confuse the existing
users. They will install the plug-in,<br>
they will not see the Administration tab and will think that
Ginger installation failed.<br>
<br>
</blockquote>
</blockquote>
<br>
Good point! From a Ginger side, I agree extending the common-host
plugin will not provide a good user experience.<br>
So I don't see problems in having both tabs while loading Ginger for
instance: Host + Administration.<br>
<br>
About renaming the Host tab to better clarification I suggest "Host
details"<br>
<br>
<blockquote cite="mid:55C4BDAB.4050205@gmail.com" type="cite">
<blockquote cite="mid:55C4BCE9.1070700@gmail.com" type="cite">
Besides that, the current engine does not support a plug-in that
extends an existing tab from<br>
another plug-in. I have no idea of the amount of work this can
take.<br>
<br>
<blockquote cite="mid:55C471FB.1060004@linux.vnet.ibm.com"
type="cite"> <br>
<br>
<br>
<div class="moz-cite-prefix">On 06.08.2015 17:11, Aline Manera
wrote:<br>
</div>
<blockquote cite="mid:55C37916.3060908@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
Thanks, Walter, to send the scrum meeting summary here!<br>
<br>
Here are my thoughts on all that.<br>
<br>
First, let me clarify the proposal of each piece of cake! =)<br>
<br>
A) Wok is a *generic web server framework based on plugins*.<br>
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.<br>
<br>
B) Kimchi is a wok plugin for virtual machine management.<br>
And it is independent system platform: x86, Power or Z.<br>
<br>
C) Ginger is a wok plugin for host management.<br>
And it is independent system platform: x86, Power or Z.<br>
<br>
By now, it is all we have. So I'd like to concentrate our
effort on it.<br>
<br>
Now thinking about which features from Kimchi Host tab can
be moved to Ginger.<br>
Let do it item by item. The Host Tab is composed by:<br>
<br>
<font color="#009900">1) Restart, Shutdown, Connect
operations<br>
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.</font><br>
<br>
2) Basic Information<br>
The kind of information may be very useful to user while
manage virtual machine. Specially by the amount of memory
and number of CPUs.<br>
With that information the user can properly balance
his/her virtual machines configuration to have better system
performance.<br>
<br>
3) Host statistics <br>
The same I described on item 2.<br>
<br>
<font color="#009900">4) Software Update<br>
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.<br>
<br>
5) Repository management<br>
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.<br>
</font><br>
6) Debug reports<br>
This functionality may be interesting for virtual
machine management when some of them represents a problem or
bad performance. <br>
So user can easily grab the system logs to check what is
going wrong.<br>
<br>
So if no one opposes, we can start moving 1, 4 and 5 to
Ginger.<br>
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.<br>
The Kimchi patch must be simpler but it will require more
work on Ginger side.<br>
<br>
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.<br>
(And I hope you all do the same <span class="moz-smiley-s1"><span>
:-) </span></span>)<br>
<br>
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.<br>
<br>
As per discussion (see item A), wok is a generic framework
and should not handle those kind of APIs. (Agree?)<br>
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)<br>
While loading wok without any plugin, it should display a
simple page "Welcome to wok" or something like that but
without any functionality.<br>
<br>
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.<br>
<br>
Kimchi and Ginger will have a dependency on this common-host
plugin and will provide the proper UI for it.<br>
<br>
To do not duplicate information while loading Kimchi and
Ginger together, I propose to add a smart logic for it:<br>
<br>
- Kimchi will always load the Host tab with the common-host
plugin (as it is today).<br>
- Ginger will load the common-host plugin *only and if only*
it is running standalone.<br>
<br>
What do you think about it?<br>
<br>
Regards,<br>
Aline Manera<br>
<br>
<div class="moz-cite-prefix">On 06/08/2015 11:15, Walter
Niklaus wrote:<br>
</div>
<blockquote cite="mid:55C36C14.8070308@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Picking up the discussion from the Scrum meeting about
where (which plugin) certain functionalities should be.<br>
<br>
To make sure we don't miss this aspect, I'm re-iterating
on the high level use cases.<br>
Currently I see the following major usecases now and in
the near future (next year):<br>
1. A user wants to perform base Linux management only.<br>
- here he needs all the generic Host-Management
functionality + the platform specific stuff like: <br>
Power-FW code update, Energy Management on Power
or IO-Device Management on System z<br>
2. A user wants to manage KVM Virtual Machines. <br>
- his primary scope are VMs. How much of the Host
and Platform specific Management functionality is required
here ?<br>
3. A user wants to manage Containers.<br>
- his primary scope are Container. How much of the
Host and Platform specific Management functionality is
required here ?<br>
4. A user wants to manage Containers and KVM Virtual
Machines .<br>
- his primary scope are Container and VMs. How much
of the Host and Platform specific Management functionality
is required here ?<br>
<br>
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.<br>
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: <br>
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.<br>
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.<br>
<br>
What could be the reasons a user would want to pick
selectively ?<br>
a. functionality not required or maybe even
conflicting with some other tooling: for example Software
Updates <br>
are managed from some central instance <br>
b. installing a reduced functionset could reduce the
external package dependencies and could reduce the amount
of updates<br>
c. simplification on the UI by eliminating unrequired
stuff<br>
<br>
Ideally the user could choose on an individual
functionality base and configure the tool based on his
needs. <br>
I guess satisfying the reasons a. and c. from above could
be implemented via UI customisation even on an individual
Kimchi/Ginger user base.<br>
Reason b. can be probably achieved only by segregating the
set of fuctionality in separate plugins.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 04.08.2015 17:26, Walter
Niklaus wrote:<br>
</div>
<blockquote cite="mid:55C0D9B2.2050701@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
... Daniel sorry for the duplicate send, I missed to
reply to all so the mail didn't go to the mailing list.<br>
<br>
<div class="moz-cite-prefix">On 04.08.2015 14:39, Daniel
Henrique Barboza wrote:<br>
</div>
<blockquote
cite="mid:55C0B29F.7050806@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 08/04/2015 04:56 AM,
Walter Niklaus wrote:<br>
</div>
<blockquote
cite="mid:55C07029.5060901@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Hi Daniel,<br>
<br>
sorry for missing the thread where this topic was
discussed.<br>
<br>
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.<br>
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 ?<br>
</blockquote>
<br>
If we're really going in that approach (putting basic
features in WoK), I agree. We would have to<br>
discuss each existing feature and evaluate if it
belongs to kimchi, ginger or wok.<br>
</blockquote>
<br>
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.<br>
Currently I see the following major usecases now and in
the near feature:<br>
1. A user wants to perform base Linux management
only.<br>
2. A user wants to manage KVM Virtual Machines. <br>
3. A user wants to manage Containers.<br>
4. A user wants to manage Containers and KVM Virtual
Machines .<br>
<br>
For the usecases 2, 3 and 4 the user needs usecase 1 as
well in order to prepare and manage the Host machine.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:55C0B29F.7050806@linux.vnet.ibm.com"
type="cite"> <br>
<blockquote
cite="mid:55C07029.5060901@linux.vnet.ibm.com"
type="cite"> <br>
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 ?<br>
<br>
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.<br>
</blockquote>
<br>
At this moment Ginger can handle multi-arch features
fairly well. For example, Firmware<br>
Update does not appear when running the plug-in in an
Intel computer. The feature you mentioned,<br>
IO-device management for Linux on Z, would be
available only when running Ginger in a Linux<br>
for Z host. <br>
<br>
There's absolutely nothing holding you from making a
brand new plug-in for the Z features instead<br>
of adding them to Ginger, but it is important to know
that Ginger is designed for these scenarios.<br>
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<br>
like a brand new plug-in working together with Ginger
common features in the 'Administration' tab.<br>
<br>
<blockquote
cite="mid:55C07029.5060901@linux.vnet.ibm.com"
type="cite"> <br>
Please let me know what you think about this option.<br>
<br>
Thanks,<br>
Walter.<br>
<br>
<br>
<div class="moz-cite-prefix">On 03.08.2015 18:51,
Daniel Henrique Barboza wrote:<br>
</div>
<blockquote
cite="mid:55BF9C0C.4080205@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Hi Walter,<br>
<br>
We've had this discussion with the community a few
months ago in the thread<br>
<br>
"[RFC] Moving some features of Host tab to Ginger"<br>
<br>
And we agreed to start it by moving only Software
Update, Repositories and <br>
Debug Reports from Kimchi to Ginger.<br>
<br>
The Basic Information and System Statistics can't
be taken away from Kimchi because there<br>
are relevant information for the creation of VMs
there, such as Memory Available. But I agree<br>
that these information fits nicely in Ginger too.<br>
<br>
One alternative (just came in my head now) is to
move these "neutral" functions<br>
to a "Basic System Info" in WoK. That way both
Kimchi and Ginger users can access<br>
the information. <br>
<br>
<br>
Thanks,<br>
<br>
<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 08/03/2015 12:15
PM, Walter Niklaus wrote:<br>
</div>
<blockquote
cite="mid:55BF858A.4020103@linux.vnet.ibm.com"
type="cite"> <br>
After separating out Kimchi as an indvidual
plugin from the base <br>
framework it would be great to have a clean
separation between Host- and <br>
Virtualization Management functions. I'm
planning to work on this topic <br>
in the next few weeks and have prepared a
proposal of the functionsplit. <br>
Plugin functionality: <br>
- Ginger: <br>
- Basic Information <br>
- System Statistics <br>
- Network (Host NICs) <br>
- Storage/SAN (Host Storage) <br>
- User Management <br>
- Configuration Backup <br>
- Software Updates <br>
- Repositories <br>
- Debug Reports <br>
- PPC related functions: Firmware
Update & Power Management <br>
- Kimchi: <br>
- Templates <br>
- Guests <br>
- Networks (virtual) <br>
- Storage (Pools for VMs) <br>
<br>
Since there are plans to restructure the UI for
one of the next <br>
releases, I'm proposing to do only some minimal
investments in <br>
reflecting this new finctionsplit. Therefore I'm
proposing to make the <br>
Host tab as the one and only Tab for Ginger and
move everything from the <br>
Administration Tab into the Host Tab. This
would be just an <br>
intermediate solution till we implement the new
UI design. Please see <br>
the attached PDF. <br>
Thanks in advance for your feedback. <br>
<br>
Walter. <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>