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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel