Hi,
      
      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.
      
      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.
      
      Plugin ginger-basic:
      Base Information
          Basic Info
          Host Stats
          Debug Reports
      
      Plugin ginger :
      System
          Software Update
          Repositories
          Restart, Shutdown of Host
      Hot-plug
      Networks
      Storage
      Security
          Firewalls
          SELinux
          PAM Config
      Configuration
          Dumps
          Backups
          Systemd
              ...
      Console
      Users and Groups
      
      Plugin ginger-ppc :
      Firmware Updates
      IBM SEP
      Energy Management
      
      Plugin ginger-s390x :
      HPM
      Performance Metrics and Diagnostics
      zIO Management
      
    **Note :
        Hot-plug, Security, dumps and systemd configurations etc  will
        be kind of future functionality that can be part of base ginger
        plugin.
        
      Key points to consider:
      1. At the moment separation of the ginger-ppc part of
      functionality (mentioned above) from the ginger may not be the
      highest priority. 
      2. Shall we keep Users and Groups part of ginger plugin or do we
      want this be part of base WOK frame work ?
    
    Let me know
      what do you think about this !!!
      
      Regards
      Chandra
    On 08/07/2015 09:51 PM, Daniel Henrique
      Barboza wrote:
    
     
      
      On 08/07/2015 01:14 PM, Walter Niklaus wrote: 
       
        
        On 07.08.2015 18:05, Aline Manera wrote: 
         
          Seems we are close to a conclusion on that subject. ;-) 
          
          Let me resume what we have already agreed: 
          
          1) Move software update + repositories + restart + shutdown +
          console to Ginger 
          
          2) Create a new plugin for host basic info + host stats +
          debug reports 
          
          My proposal is to have this new plugin under Ginger community
          responsibility. 
          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. 
          
          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. 
          And 'ginger' plugin will extend this Host tab generated by
          ginger-basic. 
          
          It will increase the Ginger community scope and make everyone
          happy! =) 
          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) 
          
          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. 
          In a simple phrase, Ginger plugins provide a Host tab based on
          wok framework. 
          
          To do not get the user crazy "Where is Ginger now?" while
          loading the updated version, I have 2 suggestion: 
          
          A) Work with plugin logos! 
              Maybe a pan design to represent wok framework and on top
          of it all the plugins logos are displayed. 
              To do that we will need a logo for wok and ginger. 
          
          B) Create a introduction page to show the differences from the
          older version. 
              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"... 
          
        
        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 :-) 
        
        Do you agree, Daniel and Walter? 
          
        
        I agree. 
      
      
      I agree. Unless someone else has a strong point against it, we can
      move forward with this idea, 
      starting discussions about what needs to be done and how long
      we'll need to make it happen. From 
      the top of my head the most critical point is how to make the
      current engine support a plug-in 
      extends an existing plug-in. We can start there. 
      
       
        Regards, 
          Aline Manera 
        
        
      
      
      _______________________________________________ 
      Kimchi-devel mailing list 
      Kimchi-devel@ovirt.org
      
      http://lists.ovirt.org/mailman/listinfo/kimchi-devel