Open Stack

Hi,

I would go with the 1st approach. The thing I don't like in the 2nd
approach is that we have to make the user enable plugin twice. For example,
we have to enable Ceph as a plugin and then add Ceph role to nodes and
choose what we want to store in Ceph (images, objects). Why we would need
to explicitly enable Ceph plugin? Let's always show plugin options in
wizard and settings tab, and if the user just doesn't want to enable Ceph,
he would just leave all the checkboxes unchecked. The 2nd approach would
also lead to some kind of inconsistency in case the user enabled Ceph
plugin but left all the Ceph-related checkboxes unchecked and didn't add
Ceph nodes.

2014-10-07 21:17 GMT+07:00 Evgeniy L <eli at mirantis.com>:

> 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,
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141008/8037c793/attachment.html>