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

[Aline Manera]

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

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