<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
... Danie 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>
</body>
</html>