<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 16: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>
      </blockquote>
    </blockquote>
    <br>
    Administration isn't really specific about being host management. I
    guess the only aspect matching this description may be User
    Management and all these aspects we are discussing are Host related.<br>
    <br>
    <blockquote cite="mid:55C4BDAB.4050205@gmail.com" type="cite">
      <blockquote cite="mid:55C4BCE9.1070700@gmail.com" type="cite"> 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>
    Can we document this ? And we are talking about a new release, based
    on a new UI-Design. <br>
    Otherwise we would have to stick to current UI design and layout
    forever.  Applying design thinking may introduce some additional
    changes but I feel as long as we are doing a good job in providing
    an intuitive UI, the user will adapt very easy.<br>
    <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>
    </blockquote>
    I would hope that with the new UI design, this restriction isn't
    there anymore. Of course we have to look at the effort.<br>
    But I would like to exploit this feature in other situations as well
    since I'm planning to have the IO-management for System z as a
    separate plugin.<br>
    <br>
    <blockquote cite="mid:55C4BDAB.4050205@gmail.com" type="cite">
      <blockquote cite="mid:55C4BCE9.1070700@gmail.com" type="cite">
        <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 &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>
              <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>
    </blockquote>
    <br>
  </body>
</html>