[Kimchi-devel] [RFC] Plugin management - disable/enable WoK plug-ins
Daniel Henrique Barboza
danielhb at linux.vnet.ibm.com
Wed Jan 11 18:59:10 UTC 2017
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.
>
>> 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
>
More information about the Kimchi-devel
mailing list