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

On 01/17/2017 10:03 AM, Aline Manera wrote: > > > 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. > Oh I see. I'll consider it when I look into how to work with plugin dependencies again. Daniel >> 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 > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel