[Kimchi-devel] [RFC] Plugin management - disable/enable WoK plug-ins
Daniel Henrique Barboza
dhbarboza82 at gmail.com
Wed Jan 18 09:22:10 UTC 2017
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
On 01/17/2017 10:07 AM, Daniel Henrique Barboza wrote:
>
>
> On 01/17/2017 10:03 AM, Aline Manera wrote:
>>
>>
>> On 01/16/2017 05:18 PM, Daniel Henrique Barboza wrote:
>>>
>>>
>>> On 01/11/2017 05:03 PM, Aline Manera wrote:
>>>>
>>>>
>>>> On 01/11/2017 04:59 PM, Daniel Henrique Barboza wrote:
>>>>>
>>>>>
>>>>> On 01/11/2017 03:46 PM, Aline Manera wrote:
>>>>>>
>>>>>> Hi Daniel,
>>>>>>
>>>>>> On 01/10/2017 10:24 AM, Daniel Henrique Barboza wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> I am working in a way to enable/disable WoK plug-ins using an
>>>>>>> API. This is
>>>>>>> what we already have regarding plugin management:
>>>>>>>
>>>>>>> - each plug-in has a configuration file, for example ginger.conf:
>>>>>>>
>>>>>>> [wok]
>>>>>>> # Enable Ginger plugin on Wok server (values: True|False)
>>>>>>> enable = True
>>>>>>>
>>>>>>> (...)
>>>>>>>
>>>>>>>
>>>>>>> - an API that returns all enable plug-ins:
>>>>>>>
>>>>>>> $ curl -k -u danielhb -H "Content-Type: application/json" -H
>>>>>>> "Accept: application/json" -X GET 'https://localhost:8001/plugins'
>>>>>>> Enter host password for user 'danielhb':
>>>>>>> [
>>>>>>> "gingerbase",
>>>>>>> "kimchi",
>>>>>>> "ginger"
>>>>>>> ]
>>>>>>>
>>>>>>> The API retrieves the contents of each plug-in config file and
>>>>>>> return the
>>>>>>> plug-in name if enable = True.
>>>>>>>
>>>>>>>
>>>>>>> This is my proposal to implement this new feature without
>>>>>>> messing around
>>>>>>> too much:
>>>>>>>
>>>>>>> - the /plugins API will now returns all plug-ins, regardless of
>>>>>>> the plug-in being
>>>>>>> loaded or not. In the previous example the returned value would be:
>>>>>>>
>>>>>>> [{ "name: "gingerbase", "enabled": True} ,
>>>>>>> { "name: "ginger", "enabled": True},
>>>>>>> { "name: "kimchi", "enabled": True} ]
>>>>>>>
>>>>>>
>>>>>> If you are saying to keep /plugins as a SimpleColletion, I do not
>>>>>> agree on that.
>>>>>>
>>>>>> The /plugins API should be changed to be a Collection of Resources.
>>>>>> So GET /plugins will return all the plugins (the same way you did
>>>>>> above) and GET /plugins/*name* will return the information about
>>>>>> a single plugin.
>>>>>>
>>>>>>>
>>>>>>> Changes in the existing API calls will be made considering this
>>>>>>> new format.
>>>>>>>
>>>>>>> - A new PUT method to change the 'enabled' attribute of the
>>>>>>> plug-ins. Changing
>>>>>>> the attribute will write the new value in the plug-in config
>>>>>>> file, allowing WoK
>>>>>>> to enable/disable the plug-in in the next reboot.
>>>>>>>
>>>>>>
>>>>>> The action enable/disable should be a POST method on a Resource
>>>>>> elemente instead of PUT.
>>>>>>
>>>>>> POST /plugins/*name*/enable
>>>>>> POST /plugins/*name*/disable
>>>>>>
>>>>>>> - To make the changes effective we need to reboot WoK after
>>>>>>> enabling/disabling
>>>>>>> a plug-in. This can be done by either rebooting WoK in the same
>>>>>>> PUT operation I
>>>>>>> mentioned above or by a new 'reboot' API in WoK. I am more fond
>>>>>>> of a new API
>>>>>>> but I can live with this 'super PUT' API too.
>>>>>>>
>>>>>>
>>>>>> I am OK to add a new API to reload the server configuration.
>>>>>>
>>>>>>>
>>>>>>> Note that at this moment we will not supporting load/unload of
>>>>>>> plug-ins without
>>>>>>> rebooting WoK. This has proven to be challenging considering our
>>>>>>> current
>>>>>>> plug-in loading schema in cherrypy.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>> You should consider the plugins dependencies as well.
>>>>>>
>>>>>> Kimchi depends on Ginger Base UI to build the Peers feature UI.
>>>>>> So disabling Ginger Base implies in disabling Kimchi.
>>>>>> What about Ginger? And Ginger s390x?
>>>>>
>>>>> I wasn't planning to do the plug-in dependencies in this first
>>>>> version, but
>>>>> my plan would be to add a 'DEPENDS_ON' attribute in the config
>>>>> file of each
>>>>> plug-in with the plug-in dependencies. So for example in kimchi.conf:
>>>>>
>>>>> DEPENDS_ON=ginger-base
>>>>>
>>>>>
>>>>> and on gingers390x:
>>>>>
>>>>> DEPENDS_ON=ginger-base,ginger
>>>>>
>>>>>
>>>>> And then when disabling Gingerbase we can disable all plug-ins
>>>>> that depends
>>>>> on it.
>>>>
>>>> The plugin configuration file should only contain data which can be
>>>> changed by the user.
>>>> In that case, the dependency should never be changed.
>>>>
>>>> Said that, I'd suggest to follow the same approach used to extend
>>>> the UI of another plugin.
>>>> Check for self.extends in WokRoot and Ginger/Ginger s390x
>>>>
>>>
>>> Just checked it. Problem is that it is not mandatory - it is only
>>> needed when you're extending
>>> the UI of a plug-in. Ginger is dependent of Gingerbase but doesn't
>>> extend Gingerbase UI, so
>>> Ginger does not have this self.extends mechanic.
>>>
>>
>> I am not saying to you reuse the self.extends for the proposal of
>> dependencies.
>> I am saying to you create a new parameter self.depends (for example)
>> which will be behave the same as self.extends, ie, when set by the
>> plugin that information will be used.
>>
>
> Oh I see. I'll consider it when I look into how to work with plugin
> dependencies again.
>
>
> Daniel
>
>
>>> Besides, I would rather not poke into the plug-in backend internals
>>> to discover its dependencies.
>>> Each plug-in can do it differently and it would be too much to
>>> handle in WoK level.
>>>
>>> My suggestion in this case would be to create a new file in each
>>> plug-in, something like
>>> 'wok_dependencies', that contains all plug-in dependencies for that
>>> plug-in. The absence of this
>>> file would be interpreted as having no plug-in dependencies. That
>>> way we have a standard way of
>>> knowing the dependencies of each plug-in in WoK level.
>>>
>>>
>>> ps: I'll go ahead and implement the following APIs
>>>
>>> POST /plugins/*name*/enable
>>> POST /plugins/*name*/disable
>>>
>>> and change /plugins to be a Collection instead of a SimpleCollection
>>> as it is now.
>>> Meanwhile we can keep discussing how to discover the plug-in
>>> dependencies in
>>> WoK level.
>>>
>>>
>>> Daniel
>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>>
>>>>>>> Daniel
>>>>>>> _______________________________________________
>>>>>>> Kimchi-devel mailing list
>>>>>>> Kimchi-devel at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kimchi-devel mailing list
>>>>>> Kimchi-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kimchi-devel mailing list
>>>>> Kimchi-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
More information about the Kimchi-devel
mailing list