<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 11/08/2015 10:06, Walter Niklaus
      wrote:<br>
    </div>
    <blockquote cite="mid:55C9F33C.70909@linux.vnet.ibm.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <br>
      <br>
      <div class="moz-cite-prefix">Am 10.08.2015 um 19:44 schrieb Daniel
        Henrique Barboza:<br>
      </div>
      <blockquote cite="mid:55C8E301.7010102@gmail.com" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        <br>
        <br>
        <div class="moz-cite-prefix">On 08/10/2015 02:31 PM, Chandra
          Shehkhar Reddy Potula <a moz-do-not-send="true"
            class="moz-txt-link-abbreviated"
            href="mailto:chandra@linux.vnet.ibm.com">chandra@linux.vnet.ibm.com</a>
          [ginger-dev] wrote:<br>
        </div>
        <blockquote cite="mid:55C8DFDC.1030806@linux.vnet.ibm.com"
          type="cite">
          <meta content="text/html; charset=windows-1252"
            http-equiv="Content-Type">
          <font face="Cantarell">Hi,<br>
            <br>
            It is good idea to modularize the host functionality as
            plugins.  Keeping common host functionality as a one plugin
            and at the same time having platform specific host
            functionality as additional plugins gives choice of picking
            up the relevant features on specific platform.<br>
            <br>
            Since we had an agreement on the movement of host
            functionality from kimchi to ginger, here is draft proposal
            I have to modularize the ginger functionality.<br>
            <br>
            <b>Plugin ginger-basic:</b><br>
            Base Information<br>
                Basic Info<br>
                Host Stats<br>
                Debug Reports<br>
            <br>
            <b>Plugin ginger :</b><br>
            System<br>
                Software Update<br>
                Repositories<br>
                Restart, Shutdown of Host<br>
            Hot-plug<br>
            Networks<br>
            Storage<br>
            Security<br>
                Firewalls<br>
                SELinux<br>
                PAM Config<br>
            Configuration<br>
                Dumps<br>
                Backups<br>
                Systemd<br>
                    ...<br>
            Console<br>
            Users and Groups<br>
            <br>
            <b>Plugin ginger-ppc :</b><br>
            Firmware Updates<br>
            IBM SEP<br>
            Energy Management<br>
          </font></blockquote>
        Energy management isn't exclusive to Power. It works in x86_64
        too.<br>
        <br>
        <blockquote cite="mid:55C8DFDC.1030806@linux.vnet.ibm.com"
          type="cite"><font face="Cantarell"> <br>
            <b>Plugin ginger-s390x :</b><br>
            HPM<br>
            Performance Metrics and Diagnostics<br>
          </font></blockquote>
        <br>
        This feature can be multi-architecture if the tools used to get
        the metrics/diagnostics aren't<br>
        exclusive to Z.<br>
      </blockquote>
      Makes sense, we should try to make this one platform independent.
      I guess we are not there yet, but we should plan for.<br>
      <br>
      <blockquote cite="mid:55C8E301.7010102@gmail.com" type="cite"> <br>
        <blockquote cite="mid:55C8DFDC.1030806@linux.vnet.ibm.com"
          type="cite"><font face="Cantarell"> zIO Management<br>
            <br>
          </font><font face="Cantarell"><font face="Cantarell">**<b>Note</b>
              : Hot-plug, Security, dumps and systemd configurations
              etc  will be kind of future functionality that can be part
              of base ginger plugin.<br>
              <br>
            </font><b>Key points to consider:</b><br>
            1. At the moment separation of the ginger-ppc part of
            functionality (mentioned above) from the ginger may not be
            the highest priority. <br>
            2. Shall we keep Users and Groups part of ginger plugin or
            do we want this be part of base WOK frame work ?</font><br>
        </blockquote>
        <br>
        The idea is to keep the WOK framework 'featureless'. It will
        consist only in the cherrypy server,<br>
        model/control APIs and a 'Welcome to WOK' message when no
        plug-in is installed.<br>
      </blockquote>
      Keeping wok featurelss makes lot of sense. I guess what we need to
      think about is the scope of user and roles management. From what I
      currently see there are currently 3 roles/profiles defined:
      Administrator, Kimchi User and Virt User.  With the agreed feature
      split User Management is available only if Ginger is installed,
      which is true with the current stable implementation as well.
      Since in the current implementation Kimchi is always available we
      don't have an issue offering Kimchi and Virt User profiles by
      default, but after the separation these profiles make sense only
      if Kimchi plugin is installed. Theoretically any new plugin could
      bring in the requirement of new profiles. <br>
      The other question we have to clarify is:  do we need User
      Management when Ginger is not available as plugin ?  <br>
      From the implementation I understand that we are talking here only
      about locally (on this host) defined users and roles, ldap user
      management isn't performed. From this point of view it's fitting
      in the scope of Host Management. The part not really fitting is
      the plugin specific profile aspect.<br>
      Since we want to keep the plugins as independent as possible from
      each other, one option I see is: if a certain plugin has the
      requirement for a certain user role it has to expose the
      description of this role in a tbd. format to the User Management
      feature.<br>
      <br>
    </blockquote>
    <br>
    In the current wok implementation we have 2 types of users: admin
    and user.<br>
    Each plugin specify the user access by the config/ui/tabs.xml file.<br>
    <br>
    The profiles associated to a user through the users and groups
    management provided by Ginger there is nothing related to the
    authorization settings - at least by now.<br>
    (And AFAIK, there is no plan to associate them.)<br>
    <br>
    If it is the new focus of this conversation, I suggest to create a
    new email thread with a well documented proposal for wok and its
    plugins.<br>
    <br>
    <blockquote cite="mid:55C9F33C.70909@linux.vnet.ibm.com" type="cite">
      <blockquote cite="mid:55C8E301.7010102@gmail.com" type="cite">
        <blockquote cite="mid:55C8DFDC.1030806@linux.vnet.ibm.com"
          type="cite"> <br>
          <font face="Cantarell">Let me know what do you think about
            this !!!<br>
          </font></blockquote>
        <br>
        Just a reminder: we still need to figure it out how we'll change
        the current engine to support a<br>
        plug-in extending an existing tab from another plug-in. <br>
      </blockquote>
      We are working on that one.  If it proofs to be too much of work
      or uggly hack, I would propose to leave it how it is for now in
      the old UI-design (meaning keep Administration tab)  and do the
      final UI-restructuring based on the new UI-Design.<br>
      <br>
      <br>
      <blockquote cite="mid:55C8E301.7010102@gmail.com" type="cite"> <br>
        <br>
        And another reminder: Ginger mailing list is now <a
          moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="mailto:ginger-dev-list@nongnu.org">ginger-dev-list@nongnu.org</a>.
        Feel free to join<br>
        the ML: <br>
        <br>
        <meta http-equiv="content-type" content="text/html;
          charset=windows-1252">
        <a moz-do-not-send="true"
          href="https://lists.nongnu.org/mailman/listinfo/ginger-dev-list"
          style="box-sizing: border-box; color: rgb(64, 120, 192);
          text-decoration: none; font-family: 'Helvetica Neue',
          Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size:
          16px; font-style: normal; font-variant: normal; font-weight:
          normal; letter-spacing: normal; line-height:
          20.4799995422363px; orphans: auto; text-align: left;
          text-indent: 0px; text-transform: none; white-space: normal;
          widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;
          background-color: rgb(255, 255, 255);">https://lists.nongnu.org/mailman/listinfo/ginger-dev-list</a><span
          style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue',
          Helvetica, 'Segoe UI', Arial, freesans, sans-serif; font-size:
          16px; font-style: normal; font-variant: normal; font-weight:
          normal; letter-spacing: normal; line-height:
          20.4799995422363px; orphans: auto; text-align: left;
          text-indent: 0px; text-transform: none; white-space: normal;
          widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;
          display: inline !important; float: none; background-color:
          rgb(255, 255, 255);"><span class="Apple-converted-space">    
          </span></span><br>
        <br>
        <br>
        <br>
        Daniel<br>
        <br>
        <blockquote cite="mid:55C8DFDC.1030806@linux.vnet.ibm.com"
          type="cite"><font face="Cantarell"> <br>
            Regards<br>
            Chandra</font><br>
          <div class="moz-cite-prefix">On 08/07/2015 09:51 PM, Daniel
            Henrique Barboza wrote:<br>
          </div>
          <blockquote cite="mid:55C4DAF6.40008@gmail.com" type="cite"> <br>
            <br>
            On 08/07/2015 01:14 PM, Walter Niklaus wrote: <br>
            <blockquote type="cite"> <br>
              <br>
              On 07.08.2015 18:05, Aline Manera wrote: <br>
              <blockquote type="cite"> <br>
                Seems we are close to a conclusion on that subject. ;-)
                <br>
                <br>
                Let me resume what we have already agreed: <br>
                <br>
                1) Move software update + repositories + restart +
                shutdown + console to Ginger <br>
                <br>
                2) Create a new plugin for host basic info + host stats
                + debug reports <br>
                <br>
                My proposal is to have this new plugin under Ginger
                community responsibility. <br>
                AFAIU, the Ginger community is for a host management
                plugin. And as this new plugin is for basic host
                details, it makes all sense for me. <br>
                <br>
                Thinking on that, I suggest to name this new plugin as
                'ginger-basic' which will load a tab named 'Host' with
                host basic information + host stats + debug reports. <br>
                And 'ginger' plugin will extend this Host tab generated
                by ginger-basic. <br>
                <br>
                It will increase the Ginger community scope and make
                everyone happy! =) <br>
                We can also think about splitting ginger into: ginger,
                ginger-ppc, ginger-z, etc... (but it is an other
                different topic to be discussed on Ginger community) <br>
                <br>
                So from a user and devel perspective, the whole Kimchi
                Host tab will be moved to Ginger community into 2
                different plugins: ginger-basic and ginger. <br>
                In a simple phrase, Ginger plugins provide a Host tab
                based on wok framework. <br>
                <br>
                To do not get the user crazy "Where is Ginger now?"
                while loading the updated version, I have 2 suggestion:
                <br>
                <br>
                A) Work with plugin logos! <br>
                    Maybe a pan design to represent wok framework and on
                top of it all the plugins logos are displayed. <br>
                    To do that we will need a logo for wok and ginger. <br>
                <br>
                B) Create a introduction page to show the differences
                from the older version. <br>
                    The idea behind it is like some Android applications
                do when get updated. Once you open it, a page is
                displayed as a layer on top of the application with
                balloons and arrows to tell "this feature was moved to
                here"... <br>
                <br>
              </blockquote>
              I'm ok with both solutions although since we are planning
              to redesign the UI in order to improve the user experience
              I hope that we are able to do a very good job and make the
              new UI-design intuitive enough for the user to find the
              right menue points :-) <br>
              <br>
              <blockquote type="cite">Do you agree, Daniel and Walter? <br>
                <br>
              </blockquote>
              I agree. <br>
            </blockquote>
            <br>
            I agree. Unless someone else has a strong point against it,
            we can move forward with this idea, <br>
            starting discussions about what needs to be done and how
            long we'll need to make it happen. From <br>
            the top of my head the most critical point is how to make
            the current engine support a plug-in <br>
            extends an existing plug-in. We can start there. <br>
            <br>
            <blockquote type="cite"> <br>
              <blockquote type="cite">Regards, <br>
                Aline Manera <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
            _______________________________________________ <br>
            Kimchi-devel mailing list <br>
            <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
              href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
            <br>
            <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>
            <br>
            <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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Kimchi-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kimchi-devel@ovirt.org">Kimchi-devel@ovirt.org</a>
<a 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>
  </body>
</html>