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

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.

> >> 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