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

Tue Jan 17 12:07:21 UTC 2017

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
>