9:18 p.m.
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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel