Re: [Kimchi-devel] [RFC] Plugin management - disable/enable WoK plug-ins

On 01/11/2017 05:03 PM, Aline Manera wrote: > > > On 01/11/2017 04:59 PM, Daniel Henrique Barboza wrote: >> >> >> On 01/11/2017 03:46 PM, Aline Manera wrote: >>> >>> Hi Daniel, >>> >>> On 01/10/2017 10:24 AM, Daniel Henrique Barboza wrote: >>>> Hi there, >>>> >>>> I am working in a way to enable/disable WoK plug-ins using an API. >>>> This is >>>> what we already have regarding plugin management: >>>> >>>> - each plug-in has a configuration file, for example ginger.conf: >>>> >>>> [wok] >>>> # Enable Ginger plugin on Wok server (values: True|False) >>>> enable = True >>>> >>>> (...) >>>> >>>> >>>> - an API that returns all enable plug-ins: >>>> >>>> $ curl -k -u danielhb -H "Content-Type: application/json" -H >>>> "Accept: application/json" -X GET 'https://localhost:8001/plugins' >>>> Enter host password for user 'danielhb': >>>> [ >>>> "gingerbase", >>>> "kimchi", >>>> "ginger" >>>> ] >>>> >>>> The API retrieves the contents of each plug-in config file and >>>> return the >>>> plug-in name if enable = True. >>>> >>>> >>>> This is my proposal to implement this new feature without messing >>>> around >>>> too much: >>>> >>>> - the /plugins API will now returns all plug-ins, regardless of >>>> the plug-in being >>>> loaded or not. In the previous example the returned value would be: >>>> >>>> [{ "name: "gingerbase", "enabled": True} , >>>> { "name: "ginger", "enabled": True}, >>>> { "name: "kimchi", "enabled": True} ] >>>> >>> >>> If you are saying to keep /plugins as a SimpleColletion, I do not >>> agree on that. >>> >>> The /plugins API should be changed to be a Collection of Resources. >>> So GET /plugins will return all the plugins (the same way you did >>> above) and GET /plugins/*name* will return the information about a >>> single plugin. >>> >>>> >>>> Changes in the existing API calls will be made considering this >>>> new format. >>>> >>>> - A new PUT method to change the 'enabled' attribute of the >>>> plug-ins. Changing >>>> the attribute will write the new value in the plug-in config file, >>>> allowing WoK >>>> to enable/disable the plug-in in the next reboot. >>>> >>> >>> The action enable/disable should be a POST method on a Resource >>> elemente instead of PUT. >>> >>> POST /plugins/*name*/enable >>> POST /plugins/*name*/disable >>> >>>> - To make the changes effective we need to reboot WoK after >>>> enabling/disabling >>>> a plug-in. This can be done by either rebooting WoK in the same >>>> PUT operation I >>>> mentioned above or by a new 'reboot' API in WoK. I am more fond of >>>> a new API >>>> but I can live with this 'super PUT' API too. >>>> >>> >>> I am OK to add a new API to reload the server configuration. >>> >>>> >>>> Note that at this moment we will not supporting load/unload of >>>> plug-ins without >>>> rebooting WoK. This has proven to be challenging considering our >>>> current >>>> plug-in loading schema in cherrypy. >>>> >>>> >>> >>> OK. >>> >>> You should consider the plugins dependencies as well. >>> >>> Kimchi depends on Ginger Base UI to build the Peers feature UI. So >>> disabling Ginger Base implies in disabling Kimchi. >>> What about Ginger? And Ginger s390x? >> >> I wasn't planning to do the plug-in dependencies in this first >> version, but >> my plan would be to add a 'DEPENDS_ON' attribute in the config file >> of each >> plug-in with the plug-in dependencies. So for example in kimchi.conf: >> >> DEPENDS_ON=ginger-base >> >> >> and on gingers390x: >> >> DEPENDS_ON=ginger-base,ginger >> >> >> And then when disabling Gingerbase we can disable all plug-ins that >> depends >> on it. > > The plugin configuration file should only contain data which can be > changed by the user. > In that case, the dependency should never be changed. > > Said that, I'd suggest to follow the same approach used to extend the > UI of another plugin. > Check for self.extends in WokRoot and Ginger/Ginger s390x > Just checked it. Problem is that it is not mandatory - it is only needed when you're extending the UI of a plug-in. Ginger is dependent of Gingerbase but doesn't extend Gingerbase UI, so Ginger does not have this self.extends mechanic.

Besides, I would rather not poke into the plug-in backend internals to discover its dependencies. Each plug-in can do it differently and it would be too much to handle in WoK level. My suggestion in this case would be to create a new file in each plug-in, something like 'wok_dependencies', that contains all plug-in dependencies for that plug-in. The absence of this file would be interpreted as having no plug-in dependencies. That way we have a standard way of knowing the dependencies of each plug-in in WoK level. ps: I'll go ahead and implement the following APIs POST /plugins/*name*/enable POST /plugins/*name*/disable and change /plugins to be a Collection instead of a SimpleCollection as it is now. Meanwhile we can keep discussing how to discover the plug-in dependencies in WoK level. Daniel >> >> >>> >>>> Thoughts? >>>> >>>> >>>> Daniel >>>> _______________________________________________ >>>> Kimchi-devel mailing list >>>> Kimchi-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel