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