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

[Daniel Henrique Barboza]

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


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