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

Tue Jan 17 12:03:53 UTC 2017

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.

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