[RFC] Plugin management - disable/enable WoK plug-ins
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} ] 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. - 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. 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. Thoughts? Daniel
- 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". Cheers, -- Lucio Correia
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? Daniel
Cheers,
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 (?)
Daniel
Cheers,
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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. =)
Daniel
Cheers,
_______________________________________________ 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
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?
Daniel
Cheers,
_______________________________________________ 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
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@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
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?
Thoughts?
Daniel _______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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.
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
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
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
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@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
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
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@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
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi there, Just stopped on a likely road block. Coding the /plugins/*name*/enable|disable API, I started to get 404 NotFound errors when trying a POST to /plugins/gingerbase/enable and a blank result in a GET to /plugins/gingerbase. Putting debug messages in the model class PluginModel showed that it has never been called on both cases. However, when trying a wrong URI such as /plugins/notaplugin, the model class is called and the debug messages are shown. Experimenting with the master code showed that this behavior is already live: [danielhb@arthas wok]$ curl -k -u danielhb -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/gingerbase' Enter host password for user 'danielhb': {}[danielhb@arthas wok]$ Further investigation enlightened me of the probable cause. In server.py this is how we import the plug-ins: cherrypy.tree.mount(plugin_app, config.get_base_plugin_uri(plugin_name), plugin_config) This is the code of get_base_plugin_uri: def get_base_plugin_uri(p_name): return os.path.join("/", config.get("server", "server_root"), "plugins", p_name) The API /plugin/*name* is already being used as the root URI of the plugins by cherrypy. My educated guess is that when sending a GET or a POST to it, cherrypy handles the request before reaching our model. When sending a request to a wrong URI cherrypy doesn't handle it (it doesn't know about it) and this is why I can see my debug messages when trying to get /plugins/notaplugin for example. I don't see much we can do about it - this really looks like a cherrypy default behavior. The API is using an URI that matches the cherrypy.tree.mount root of the plug-ins. I think we should avoid using it /plugins/*name* entirely. I propose an alternative: - rename the API to something else. I saw a similar work that Trujillo sent last year that called the API '/pluginsmanager' - probably he saw this behavior I've reported here too. I would call it 'pluginsinfo' but the idea is the same - rename the API to /pluginsinfo and /pluginsinfo/*name*. This is Trujillo's work for reference: http://lists.ovirt.org/pipermail/kimchi-devel/2016-June/015249.html - Being a completely different URI, it will work as intended without too much hassle. We can even keep the existing model of /plugins untouched, avoiding the changes in existing UI code that calls it today. Thoughts? We can discuss a different API name but I don't see any feasible way to implement this feature using the original /plugins and /plugins/*name* API. ps: For the record I've imagined a second alternative that would use the /plugins API as is today (SimpleCollection), reformatting its output to include plug-ins state and two additional actions 'enable_plugin' and 'disable_plugin' to take care of plug-in enablement. Then I remembered that we're talking about a SimpleCollection, not a Resource, so a POST API to take an action sounded clunky. Daniel On 01/17/2017 10:07 AM, Daniel Henrique Barboza wrote:
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@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
_______________________________________________ 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
On 18/01/2017 07:22, Daniel Henrique Barboza wrote:
Hi there,
Just stopped on a likely road block. Coding the /plugins/*name*/enable|disable API, I started to get 404 NotFound errors when trying a POST to /plugins/gingerbase/enable and a blank result in a GET to /plugins/gingerbase. Putting debug messages in the model class PluginModel showed that it has never been called on both cases.
However, when trying a wrong URI such as /plugins/notaplugin, the model class is called and the debug messages are shown.
Experimenting with the master code showed that this behavior is already live:
[danielhb@arthas wok]$ curl -k -u danielhb -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/gingerbase' Enter host password for user 'danielhb': {}[danielhb@arthas wok]$
Further investigation enlightened me of the probable cause. In server.py this is how we import the plug-ins:
cherrypy.tree.mount(plugin_app, config.get_base_plugin_uri(plugin_name), plugin_config)
This is the code of get_base_plugin_uri:
def get_base_plugin_uri(p_name): return os.path.join("/", config.get("server", "server_root"), "plugins", p_name)
The API /plugin/*name* is already being used as the root URI of the plugins by cherrypy. My educated guess is that when sending a GET or a POST to it, cherrypy handles the request before reaching our model. When sending a request to a wrong URI cherrypy doesn't handle it (it doesn't know about it) and this is why I can see my debug messages when trying to get /plugins/notaplugin for example.
I don't see much we can do about it - this really looks like a cherrypy default behavior. The API is using an URI that matches the cherrypy.tree.mount root of the plug-ins. I think we should avoid using it /plugins/*name* entirely.
I propose an alternative:
- rename the API to something else. I saw a similar work that Trujillo sent last year that called the API '/pluginsmanager' - probably he saw this behavior I've reported here too. I would call it 'pluginsinfo' but the idea is the same - rename the API to /pluginsinfo and /pluginsinfo/*name*. This is Trujillo's work for reference:
http://lists.ovirt.org/pipermail/kimchi-devel/2016-June/015249.html
- Being a completely different URI, it will work as intended without too much hassle. We can even keep the existing model of /plugins untouched, avoiding the changes in existing UI code that calls it today.
Thoughts? We can discuss a different API name but I don't see any feasible way to implement this feature using the original /plugins and /plugins/*name* API.
ps: For the record I've imagined a second alternative that would use the /plugins API as is today (SimpleCollection), reformatting its output to include plug-ins state and two additional actions 'enable_plugin' and 'disable_plugin' to take care of plug-in enablement. Then I remembered that we're talking about a SimpleCollection, not a Resource, so a POST API to take an action sounded clunky.
Daniel
One suggestion is to create a Collection /settings or Resource /configuration on Wok (it will have its own tab created under Wok UI). And /configuration/reload makes sense, since server will be restarted. If we need to be specific about plugins, we could do /settings/plugins/reload. This way /settings or /configuration would be ready to be extended for future options. -- Lucio Correia
On 01/18/2017 10:32 AM, Lucio Correia wrote:
On 18/01/2017 07:22, Daniel Henrique Barboza wrote:
Hi there,
Just stopped on a likely road block. Coding the /plugins/*name*/enable|disable API, I started to get 404 NotFound errors when trying a POST to /plugins/gingerbase/enable and a blank result in a GET to /plugins/gingerbase. Putting debug messages in the model class PluginModel showed that it has never been called on both cases.
However, when trying a wrong URI such as /plugins/notaplugin, the model class is called and the debug messages are shown.
Experimenting with the master code showed that this behavior is already live:
[danielhb@arthas wok]$ curl -k -u danielhb -H "Content-Type: application/json" -H "Accept: application/json" -X GET 'https://localhost:8001/plugins/gingerbase' Enter host password for user 'danielhb': {}[danielhb@arthas wok]$
Further investigation enlightened me of the probable cause. In server.py this is how we import the plug-ins:
cherrypy.tree.mount(plugin_app, config.get_base_plugin_uri(plugin_name), plugin_config)
This is the code of get_base_plugin_uri:
def get_base_plugin_uri(p_name): return os.path.join("/", config.get("server", "server_root"), "plugins", p_name)
The API /plugin/*name* is already being used as the root URI of the plugins by cherrypy. My educated guess is that when sending a GET or a POST to it, cherrypy handles the request before reaching our model. When sending a request to a wrong URI cherrypy doesn't handle it (it doesn't know about it) and this is why I can see my debug messages when trying to get /plugins/notaplugin for example.
I don't see much we can do about it - this really looks like a cherrypy default behavior. The API is using an URI that matches the cherrypy.tree.mount root of the plug-ins. I think we should avoid using it /plugins/*name* entirely.
I propose an alternative:
- rename the API to something else. I saw a similar work that Trujillo sent last year that called the API '/pluginsmanager' - probably he saw this behavior I've reported here too. I would call it 'pluginsinfo' but the idea is the same - rename the API to /pluginsinfo and /pluginsinfo/*name*. This is Trujillo's work for reference:
http://lists.ovirt.org/pipermail/kimchi-devel/2016-June/015249.html
- Being a completely different URI, it will work as intended without too much hassle. We can even keep the existing model of /plugins untouched, avoiding the changes in existing UI code that calls it today.
Thoughts? We can discuss a different API name but I don't see any feasible way to implement this feature using the original /plugins and /plugins/*name* API.
ps: For the record I've imagined a second alternative that would use the /plugins API as is today (SimpleCollection), reformatting its output to include plug-ins state and two additional actions 'enable_plugin' and 'disable_plugin' to take care of plug-in enablement. Then I remembered that we're talking about a SimpleCollection, not a Resource, so a POST API to take an action sounded clunky.
Daniel
One suggestion is to create a Collection /settings or Resource /configuration on Wok (it will have its own tab created under Wok UI). And /configuration/reload makes sense, since server will be restarted.
I believe we can use the already existing /config API from WoK and put the /plugins API there, such as /config/plugins/*name*. Daniel
If we need to be specific about plugins, we could do /settings/plugins/reload. This way /settings or /configuration would be ready to be extended for future options.
participants (4)
-
Aline Manera -
Daniel Henrique Barboza -
Daniel Henrique Barboza -
Lucio Correia