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

On 01/16/2017 05:18 PM, Daniel Henrique Barboza wrote: > > > 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. > I am not saying to you reuse the self.extends for the proposal of dependencies. I am saying to you create a new parameter self.depends (for example) which will be behave the same as self.extends, ie, when set by the plugin that information will be used.

> 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 > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel