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

On 01/10/2017 01:48 PM, Lucio Correia wrote: > >> >> - 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 like the idea. My only suggestion is to name that new API "reload" > (or "refresh") instead of "reboot". Ok! I believe 'reload' is more suitable. Now, I have another question: how should I develop this API? Should I create a 'server' resource and put the 'reload' POST action in it?

Daniel > > > Cheers, > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

On 01/11/2017 03:49 PM, Aline Manera wrote: > > > On 01/11/2017 10:30 AM, Daniel Henrique Barboza wrote: >> >> >> On 01/10/2017 01:48 PM, Lucio Correia wrote: >>> >>>> >>>> - 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 like the idea. My only suggestion is to name that new API >>> "reload" (or "refresh") instead of "reboot". >> >> Ok! I believe 'reload' is more suitable. >> >> Now, I have another question: how should I develop this API? Should >> I create >> a 'server' resource and put the 'reload' POST action in it? >> >> > > Maybe add that action to /config API. > > POST /config/reload (?) > That will require to set the /config/reload as protected behind authorization/authetication, ie, only admin users logged into Wok should be able to use this API. **BUT** /config is a Resource not protected today because it has important information for the server UI initialization. That way we will depend on https://github.com/kimchi-project/wok/issues/131 to have /config not protected BUT /config/reload protected. =)

> >> >> Daniel >> >>> >>> >>> Cheers, >>> >> >> _______________________________________________ >> 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

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

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.

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

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.

Thoughts? Daniel _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

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

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

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

On 18/01/2017 07:22, Daniel Henrique Barboza wrote: > Hi there, > > Just stopped on a likely road block. Coding the > /plugins/*name*/enable|disable > API, I started to get 404 NotFound errors when trying a POST to > /plugins/gingerbase/enable and a blank result in a GET to > /plugins/gingerbase. > Putting debug messages in the model class PluginModel showed that it has > never > been called on both cases. > > However, when trying a wrong URI such as /plugins/notaplugin, the model > class > is called and the debug messages are shown. > > Experimenting with the master code showed that this behavior is already > live: > > > [danielhb@arthas wok]$ curl -k -u danielhb -H "Content-Type: > application/json" -H "Accept: application/json" -X GET > 'https://localhost:8001/plugins/gingerbase' > Enter host password for user 'danielhb': > {}[danielhb@arthas wok]$ > > > Further investigation enlightened me of the probable cause. In server.py > this is > how we import the plug-ins: > > cherrypy.tree.mount(plugin_app, > config.get_base_plugin_uri(plugin_name), > plugin_config) > > > This is the code of get_base_plugin_uri: > > > def get_base_plugin_uri(p_name): > return os.path.join("/", config.get("server", "server_root"), > "plugins", p_name) > > > The API /plugin/*name* is already being used as the root URI of the > plugins by > cherrypy. My educated guess is that when sending a GET or a POST to it, > cherrypy > handles the request before reaching our model. When sending a request to > a wrong > URI cherrypy doesn't handle it (it doesn't know about it) and this is > why I can > see my debug messages when trying to get /plugins/notaplugin for > example. > > I don't see much we can do about it - this really looks like a cherrypy > default > behavior. The API is using an URI that matches the > cherrypy.tree.mount root > of the plug-ins. I think we should avoid using it /plugins/*name* > entirely. > > I propose an alternative: > > - rename the API to something else. I saw a similar work that > Trujillo sent > last year that called the API '/pluginsmanager' - probably he saw this > behavior > I've reported here too. I would call it 'pluginsinfo' but the idea is > the same - rename > the API to /pluginsinfo and /pluginsinfo/*name*. This is Trujillo's work > for reference: > > http://lists.ovirt.org/pipermail/kimchi-devel/2016-June/015249.html > > > - Being a completely different URI, it will work as intended without too > much hassle. > We can even keep the existing model of /plugins untouched, avoiding the > changes in > existing UI code that calls it today. > > > Thoughts? We can discuss a different API name but I don't see any > feasible way to > implement this feature using the original /plugins and > /plugins/*name* API. > > > > ps: For the record I've imagined a second alternative that would use the > /plugins > API as is today (SimpleCollection), reformatting its output to include > plug-ins state > and two additional actions 'enable_plugin' and 'disable_plugin' to take > care of > plug-in enablement. Then I remembered that we're talking about a > SimpleCollection, > not a Resource, so a POST API to take an action sounded clunky. > > > Daniel One suggestion is to create a Collection /settings or Resource /configuration on Wok (it will have its own tab created under Wok UI). And /configuration/reload makes sense, since server will be restarted.

If we need to be specific about plugins, we could do /settings/plugins/reload. This way /settings or /configuration would be ready to be extended for future options.