<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 06/08/2015 14:49, Harshal Patil
wrote:<br>
</div>
<blockquote
cite="mid:201508061749.t76Hnvsw025666@d28av05.in.ibm.com"
type="cite">
<div class="socmaildefaultfont" dir="ltr"
style="font-family:Arial;font-size:10.5pt">
<div dir="ltr">About 2) Basic info and 3)host stats below, do
you think wok should actually display that info in tab or
should it be just available only through API so that plugin
developers can decide to display it in whichever way they
prefer?</div>
<div dir="ltr"> </div>
</div>
</blockquote>
<br>
I have thought about it initially, but I don't agree any more as it
would break the idea of having on wok only what is needed to provide
a web server based on plugins. <br>
<br>
Because that I proposed the common-host plugin to expose the APIs.<br>
<br>
<blockquote
cite="mid:201508061749.t76Hnvsw025666@d28av05.in.ibm.com"
type="cite">
<div class="socmaildefaultfont" dir="ltr"
style="font-family:Arial;font-size:10.5pt">
<blockquote data-history-content-modified="1" dir="ltr"
style="border-left:solid #aaaaaa 2px; margin-left:5px;
padding-left:5px; direction:ltr">----- Original message -----<br>
From: Aline Manera <a class="moz-txt-link-rfc2396E" href="mailto:alinefm@linux.vnet.ibm.com"><alinefm@linux.vnet.ibm.com></a><br>
Sent by: <a class="moz-txt-link-abbreviated" href="mailto:kimchi-devel-bounces@ovirt.org">kimchi-devel-bounces@ovirt.org</a><br>
To: Walter Niklaus <a class="moz-txt-link-rfc2396E" href="mailto:niklaus@linux.vnet.ibm.com"><niklaus@linux.vnet.ibm.com></a>, Daniel
Henrique Barboza <a class="moz-txt-link-rfc2396E" href="mailto:danielhb@linux.vnet.ibm.com"><danielhb@linux.vnet.ibm.com></a>, Kimchi
Devel <a class="moz-txt-link-rfc2396E" href="mailto:kimchi-devel@ovirt.org"><kimchi-devel@ovirt.org></a><br>
Cc:<br>
Subject: Re: [Kimchi-devel] Fwd: Proposal for moving
functionality from Kimchi to Ginger<br>
Date: Thu, Aug 6, 2015 9:01 PM<br>
<br>
<!--Notes ACF
<meta content="text/html; charset=utf8"
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.</font><br>
<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><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>
<div>On 06/08/2015 11:15, Walter Niklaus wrote:</div>
<blockquote cite="mid:55C36C14.8070308@linux.vnet.ibm.com"
type="cite"><!--Notes ACF
<meta content="text/html; charset=utf8"
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>
<div>On 04.08.2015 17:26, Walter Niklaus wrote:</div>
<blockquote cite="mid:55C0D9B2.2050701@linux.vnet.ibm.com"
type="cite"><!--Notes ACF
<meta content="text/html; charset=utf8"
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>
<div>On 04.08.2015 14:39, Daniel Henrique Barboza wrote:</div>
<blockquote cite="mid:55C0B29F.7050806@linux.vnet.ibm.com"
type="cite"><!--Notes ACF
<meta content="text/html; charset=utf8"
http-equiv="Content-Type" >--><br>
<div>On 08/04/2015 04:56 AM, Walter Niklaus wrote:</div>
<blockquote
cite="mid:55C07029.5060901@linux.vnet.ibm.com"
type="cite"><!--Notes ACF
<meta content="text/html; charset=utf8"
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 ?</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.</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>
<blockquote cite="mid:55C0B29F.7050806@linux.vnet.ibm.com"
type="cite">
<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.</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>
<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>
<div>On 03.08.2015 18:51, Daniel Henrique Barboza
wrote:</div>
<blockquote
cite="mid:55BF9C0C.4080205@linux.vnet.ibm.com"
type="cite"><!--Notes ACF
<meta content="text/html; charset=utf8"
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>
<div>On 08/03/2015 12:15 PM, Walter Niklaus wrote:</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>
<fieldset> </fieldset>
<div><font size="2" face="Default
Monospace,Courier New,Courier,monospace">_______________________________________________<br>
Kimchi-devel mailing list<br>
<a href="mailto:Kimchi-devel@ovirt.org"
moz-do-not-send="true" target="_blank">Kimchi-devel@ovirt.org</a><br>
<a
href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel"
moz-do-not-send="true" target="_blank">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a></font></div>
</blockquote>
<fieldset> </fieldset>
<div><font size="2" face="Default Monospace,Courier
New,Courier,monospace">_______________________________________________<br>
Kimchi-devel mailing list<br>
<a href="mailto:Kimchi-devel@ovirt.org"
moz-do-not-send="true" target="_blank">Kimchi-devel@ovirt.org</a><br>
<a
href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel"
moz-do-not-send="true" target="_blank">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a></font></div>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<fieldset> </fieldset>
<div><font size="2" face="Default Monospace,Courier
New,Courier,monospace">_______________________________________________<br>
Kimchi-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:Kimchi-devel@ovirt.org" target="_blank">Kimchi-devel@ovirt.org</a><br>
<a moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel"
target="_blank">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a></font></div>
</blockquote>
<div><font size="2" face="Default Monospace,Courier
New,Courier,monospace">_______________________________________________<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 moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/kimchi-devel"
target="_blank">http://lists.ovirt.org/mailman/listinfo/kimchi-devel</a></font></div>
</blockquote>
<div dir="ltr"> </div>
</div>
<br>
</blockquote>
<br>
</body>
</html>