On 01/18/2017 10:32 AM, Lucio Correia wrote:
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.
I believe we can use the already existing /config API from WoK and put the /plugins API there, such as /config/plugins/*name*. Daniel
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.