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

6 Aug 2015


      On 06/08/2015 14:49, Harshal Patil wrote:
...
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?
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.

Because that I proposed the common-host plugin to expose the APIs.
...
----- Original message -----
    From: Aline Manera <alinefm@linux.vnet.ibm.com>
    Sent by: kimchi-devel-bounces@ovirt.org
    To: Walter Niklaus <niklaus@linux.vnet.ibm.com>, Daniel Henrique
    Barboza <danielhb@linux.vnet.ibm.com>, Kimchi Devel
    <kimchi-devel@ovirt.org>
    Cc:
    Subject: Re: [Kimchi-devel] Fwd: Proposal for moving functionality
    from Kimchi to Ginger
    Date: Thu, Aug 6, 2015 9:01 PM
Thanks, Walter, to send the scrum meeting summary here!
Here are my thoughts on all that.
First, let me clarify the proposal of each piece of cake! =)
A) Wok is a *generic web server framework based on plugins*.
        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.
B) Kimchi is a wok plugin for virtual machine management.
        And it is independent system platform: x86, Power or Z.
C) Ginger is a wok plugin for host management.
        And it is independent system platform: x86, Power or Z.
By now, it is all we have. So I'd like to concentrate our effort
    on it.
Now thinking about which features from Kimchi Host tab can be
    moved to Ginger.
    Let do it item by item. The Host Tab is composed by:
1) Restart, Shutdown, Connect operations
        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.
2) Basic Information
        The kind of information may be very useful to user while
    manage virtual machine. Specially by the amount of memory and
    number of CPUs.
        With that information the user can properly balance his/her
    virtual machines configuration to have better system performance.
3) Host statistics
        The same I described on item 2.
4) Software Update
        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.
5) Repository management
        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.
6) Debug reports
        This functionality may be interesting for virtual machine
    management when some of them represents a problem or bad performance.
        So user can easily grab the system logs to check what is going
    wrong.
So if no one opposes, we can start moving 1, 4 and 5 to Ginger.
    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.
    The Kimchi patch must be simpler but it will require more work on
    Ginger side.
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.
    (And I hope you all do the same :-) )
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.
As per discussion (see item A), wok is a generic framework and
    should not handle those kind of APIs. (Agree?)
    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)
    While loading wok without any plugin, it should display a simple
    page "Welcome to wok" or something like that but without any
    functionality.
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.
Kimchi and Ginger will have a dependency on this common-host
    plugin and will provide the proper UI for it.
To do not duplicate information while loading Kimchi and Ginger
    together, I propose to add a smart logic for it:
- Kimchi will always load the Host tab with the common-host plugin
    (as it is today).
    - Ginger will load the common-host plugin *only and if only* it is
    running standalone.
What do you think about it?
Regards,
    Aline Manera
    On 06/08/2015 11:15, Walter Niklaus wrote:
...
Picking up the discussion from the Scrum meeting about where
    (which plugin) certain functionalities should be.
To make sure we don't miss this aspect, I'm re-iterating on the
    high level use cases.
    Currently I see the following major usecases now and in the near
    future (next year):
      1.  A user wants to perform base Linux management only.
            - here he needs all the generic Host-Management
    functionality + the platform specific stuff like:
              Power-FW code update, Energy Management on Power or
    IO-Device Management on System z
      2.  A user wants to manage KVM Virtual Machines.
           - his primary scope are VMs. How much of the Host and
    Platform specific Management functionality is required here ?
      3.  A user wants to manage Containers.
           - his primary scope are Container. How much of the Host
    and Platform specific Management functionality is required here ?
      4.  A user wants to manage Containers and KVM Virtual Machines .
          - his primary scope are Container and VMs. How much of the
    Host and Platform specific Management functionality is required
    here ?
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.
    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:
    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.
    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.
What could be the reasons a user would want to pick selectively ?
      a.   functionality not required or maybe even conflicting with
    some other tooling: for example Software Updates
            are managed from some central instance
      b.   installing a reduced functionset could reduce the external
    package dependencies and could reduce the amount of updates
      c.   simplification on the UI by eliminating unrequired stuff
Ideally the user could choose on an individual functionality base
    and configure the tool based on his needs.
    I guess satisfying the reasons a. and c. from above could be
    implemented via UI customisation even on an individual
    Kimchi/Ginger user base.
    Reason b. can be probably achieved only by segregating the set of
    fuctionality in separate plugins.
On 04.08.2015 17:26, Walter Niklaus wrote:
...
... Daniel sorry for the duplicate send, I missed to reply to
    all so the mail didn't go to the mailing list.
    On 04.08.2015 14:39, Daniel Henrique Barboza wrote:
...
On 08/04/2015 04:56 AM, Walter Niklaus wrote:
...
Hi Daniel,
sorry for missing the thread where this topic was discussed.
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.
    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 ?
If we're really going in that approach (putting basic features
    in WoK), I agree. We would have to
    discuss each existing feature and evaluate if it belongs to
    kimchi, ginger or wok.
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.
    Currently I see the following major usecases now and in the near
    feature:
      1.  A user wants to perform base Linux management only.
      2.  A user wants to manage KVM Virtual Machines.
      3.  A user wants to manage Containers.
      4.  A user wants to manage Containers and KVM Virtual Machines .
For the usecases 2, 3 and 4 the user needs usecase 1 as well in
    order to prepare and manage the Host machine.
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.
...
...
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 ?
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.
At this moment Ginger can handle multi-arch features fairly
    well. For example, Firmware
    Update does not appear when running the plug-in in an Intel
    computer. The feature you mentioned,
    IO-device management for Linux on Z, would be available only
    when running Ginger in a Linux
    for Z host.
There's absolutely nothing holding you from making a brand new
    plug-in for the Z features instead
    of adding them to Ginger, but it is important to know that
    Ginger is designed for these scenarios.
    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
    like a brand new plug-in working together with Ginger common
    features in the 'Administration' tab.
...
Please let me know what you think about this option.
Thanks,
    Walter.
On 03.08.2015 18:51, Daniel Henrique Barboza wrote:
...
Hi Walter,
We've had this discussion with the community a few months ago
    in the thread
"[RFC] Moving some features of Host tab to Ginger"
And we agreed to start it by moving only Software Update,
    Repositories and
    Debug Reports from Kimchi to Ginger.
The Basic Information and System Statistics can't be taken
    away from Kimchi because there
    are relevant information for the creation of VMs there, such
    as Memory Available. But I agree
    that these information fits nicely in Ginger too.
One alternative (just came in my head now) is to move these
    "neutral" functions
    to a "Basic System Info" in WoK. That way both Kimchi and
    Ginger users can access
    the information.
Thanks,
Daniel
    On 08/03/2015 12:15 PM, Walter Niklaus wrote:
>
>     After separating out Kimchi as an indvidual plugin from the base
>     framework it would be great to have a clean separation
>     between Host- and
>     Virtualization Management functions. I'm planning to work on
>     this topic
>     in the next few weeks and have prepared a proposal of the
>     functionsplit.
>     Plugin functionality:
>          -  Ginger:
>                - Basic Information
>                - System Statistics
>                - Network  (Host NICs)
>                - Storage/SAN (Host Storage)
>                - User Management
>                - Configuration Backup
>                - Software Updates
>                - Repositories
>                - Debug Reports
>                - PPC related functions:  Firmware Update & Power
>     Management
>          - Kimchi:
>                -  Templates
>                -  Guests
>                -  Networks (virtual)
>                -  Storage (Pools for VMs)
>
>     Since there are plans to restructure the UI for one of the next
>     releases, I'm proposing to do only some minimal investments in
>     reflecting this new finctionsplit. Therefore I'm proposing
>     to make the
>     Host tab as the one and only Tab for Ginger and move
>     everything from the
>     Administration Tab into the Host Tab.  This would be just an
>     intermediate solution till we implement the new UI design.
>     Please see
>     the attached PDF.
>     Thanks in advance for your feedback.
>
>     Walter.
>
>
>
>
>
>
>
>
>
>     _______________________________________________
>     Kimchi-devel mailing list
>     Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org>
>     http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
    Kimchi-devel mailing list
    Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org>
    http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
    Kimchi-devel mailing list
    Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org>
    http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
    Kimchi-devel mailing list
    Kimchi-devel@ovirt.org
    http://lists.ovirt.org/mailman/listinfo/kimchi-devel

Aline Manera

tags

participants (1)