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

[Daniel Henrique Barboza]

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.

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