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

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.