Open Stack

Hi Dmitry,

>> In 1st case - in tasks we will introduce simple conditions (in
description or in python code of the plugin):

You will be able to do it in the same way in case of 2nd solution.
I mean there is no constraints on conditions defining.

>> Also, we should not forget about CLI

In case of cli we can provide special parameter and user will be able to
create env with specific plugins.

Thanks,

On Tue, Oct 7, 2014 at 6:51 PM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

> Hi, I would use 1st option.
> Consider plugins which is mutually exclusive, and you need to disable
> default tasks if plugin is selected.
>
> As example:
> - neutron backend plugins
>
> neutron_backend:
>   choices:
>     - ovs
>     - contrail
>   value: ovs
>
> Right now we are using ovs as neutron_backend, but what we will need to do
> if plugin will provide completely different backend, as contrail?
>
> In 1st case - in tasks we will introduce simple conditions (in description
> or in python code of the plugin):
> condition: 'ovs == cluster.attributes.neutron_backend' - for default
> workflow
>
> condition: 'contrail == cluster.attributes.neutron_backend' - contrail
> plugin workflow
>
> And if we need to exclude some task from workflow - simply select another
> value from drop down list.
> I believe same applies for glance/cinder backends (lvm/ceph, swift/ceph).
> Atleast we are managing them this way right now.
>
> Also, we should not forget about CLI.
> I can easily imagine how operator downloads cluster config (big cluster
> attributes file) and modifies it accordingly to turn on specific plugins.
> How we will manage plugins from cli if plugins will be managed from
> wizard?
>
>
> On Tue, Oct 7, 2014 at 5:17 PM, Evgeniy L <eli at mirantis.com> wrote:
>
>> 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
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/536c75f8/attachment.html>