[openstack-dev] [Fuel] Cinder/Neutron plugins on UI
Evgeniy L
eli at mirantis.com
Tue Oct 7 14:17:45 UTC 2014
Hi,
We had a meeting today about plugins on UI, as result of the meeting
we have two approaches and this approaches affect not only UX but
plugins itself.
*1st - disable/enable plugin on settings tab*
1. user installs the plugin
2. creates a cluster
3. configures and enables/disables plugins on settings tab
For user it will look like Ceph plugin checkboxes on settings tab,
if he enables checkbox, then we pass the parameter to orchestrator
as `true`.
Cons:
- plugin developer should define a checkbox in each plugin (for plugin
disabling/enabling)
- on the backend we have to enable all of the plugins for environment,
because user can define any name for his checkbox and we won't be able to
find it and make appropriate mapping plugin <-> env
- since all of the plugins are always "enabled" we have to run tasks for
all of the plugins, and each plugin should parse astute.yaml in order to
figure out if it's required to run task current script
Pros:
- it won't require additional setting or step for wizard
- user will be able to disable plugin after environment creation
*2nd - enable plugins in wizard*
1. user installs the plugin
2. now he can choose specific plugins for his environment in wizard
3. after cluster is created, he can configure additional parameters on
settings tab, if plugin provides any
Cons:
- user won't be able to disable plugin after cluster is created
- additional step or configuration subcategory in wizard
Pros:
On backend we always know which plugin is disabled and which is enabled.
- it means we don't provide settings for plugins which are disabled
- we don't run tasks on slaves if it's not required
Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/fd4daf58/attachment.html>
More information about the OpenStack-dev
mailing list