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

[Aline Manera]

On 01/11/2017 05:04 PM, Daniel Henrique Barboza wrote:
>
>
> On 01/11/2017 03:55 PM, Aline Manera wrote:
>>
>>
>> On 01/11/2017 03:49 PM, Aline Manera wrote:
>>>
>>>
>>> On 01/11/2017 10:30 AM, Daniel Henrique Barboza wrote:
>>>>
>>>>
>>>> On 01/10/2017 01:48 PM, Lucio Correia wrote:
>>>>>
>>>>>>
>>>>>> - 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 like the idea. My only suggestion is to name that new API 
>>>>> "reload" (or "refresh") instead of "reboot".
>>>>
>>>> Ok! I believe 'reload' is more suitable.
>>>>
>>>> Now, I have another question: how should I develop this API? Should 
>>>> I create
>>>> a 'server' resource and put the 'reload' POST action in it?
>>>>
>>>>
>>>
>>> Maybe add that action to /config API.
>>>
>>> POST /config/reload (?)
>>>
>>
>> That will require to set the /config/reload as protected behind 
>> authorization/authetication, ie, only admin users logged into Wok 
>> should be able to use this API.
>>
>> **BUT** /config is a Resource not protected today because it has 
>> important information for the server UI initialization.
>> That way we will depend on 
>> https://github.com/kimchi-project/wok/issues/131 to have /config not 
>> protected BUT /config/reload protected. =)
>
> I proposed this new API considering that it would be ankward to put an
> action inside a 'PUT' call. Considering that we go with the following 
> APIs you
> proposed:
>
> "The action enable/disable should be a POST method on a Resource 
> elemente instead of PUT.
>
> POST /plugins/*name*/enable
> POST /plugins/*name*/disable "
>
>
> I feel very comfortable adding the 'reboot' call inside each of them.
>
>
>
>
> So, a POST to /plugins/gingerbase/disable would:
>
> - edit gingerbase.conf and set it to 'disabled'
>
> - set all plug-ins that depends on Gingerbase with 'disabled' (maybe? 
> tentative? must have?
> can wait for a next interaction and assume user know what he/she is 
> doing?)
>
> - reboot WoK
>
>
>
>
> Thoughts?
>

Hrm... Just thought now about the UI.

If user is enabling/disabling N plugins, the Wok will be reboot/reload N 
times.
It is better to have it outside the enable/disable plugin API to only 
reload Wok when user has done all configuration changes.

>
>>
>>
>>>
>>>>
>>>> Daniel
>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>