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

[Lucio Correia]

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

-- 
Lucio Correia