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

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