settingsLogin | Registersettings

[openstack-dev] [Fuel] Cinder/Neutron plugins on UI

0 votes

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

asked Oct 7, 2014 in openstack-dev by Evgeniy_L (8,580 points)   1 2 4
retagged Feb 25, 2015 by admin

21 Responses

0 votes

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 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Oct 7, 2014 by Dmitriy_Shulyak (2,540 points)   4 8
0 votes

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
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 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:

responded Oct 7, 2014 by Evgeniy_L (8,580 points)   1 2 4
0 votes

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 :

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:

responded Oct 8, 2014 by Vitaly_Kramskikh (3,480 points)   2 4
0 votes

Hi,

Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff for plugins which are not even enabled and do
needless work?

This looks too complicated for me from the backend side, and option
with enabling/disabling plugins in wizard for specific environment (we
can invent mechanism to disable them on env which is not deployed yet,
besides, for API it's just one PUT) is MUCH simpler and much more
obvious, as I see.

On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
wrote:
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 :

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

user installs the plugin
creates a cluster
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

user installs the plugin
now he can choose specific plugins for his environment in wizard
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.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov

responded Oct 8, 2014 by Nikolay_Markov (1,260 points)   1 2
0 votes

If there is no checkboxes (read configuration) and plugin is installed -
all deployment tasks will be applied
to every environment, but why do you think that there will be no checkboxes
in most cases?

Right now we already have like 2 types of plugins (extensions), classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara, murano,
zabbix)

In 1st case you need to provide shared configuration storage (like cluster
attributes right now), in order for plugin
to be able to exclude part of core workflow from running (not installing
swift for example).
In case if the plugin is self-contained entity, like Sahara, Murano right
now - checkboxes would be simply required.
It works this way right now, and it doesnot look like huge overhead.

So what do you think, will it work or no?

On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov wrote:

Hi,

Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff for plugins which are not even enabled and do
needless work?

This looks too complicated for me from the backend side, and option
with enabling/disabling plugins in wizard for specific environment (we
can invent mechanism to disable them on env which is not deployed yet,
besides, for API it's just one PUT) is MUCH simpler and much more
obvious, as I see.

On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
wrote:

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 :

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

user installs the plugin
creates a cluster
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

user installs the plugin
now he can choose specific plugins for his environment in wizard
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.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


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:

responded Oct 8, 2014 by Dmitriy_Shulyak (2,540 points)   4 8
0 votes

Right now we already have like 2 types of plugins (extensions), classified by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara, murano, zabbix)

That's not quite right. In 6.0 and after that there will be a lot of
small plugins which only modify some config and/or install some
package. There is nothing to configure here, and I as a plugin
developer don't even want to know anything about checkboxes on UI. I
just want two things: role to execute my command on and command
itself. That's one small YAML.

And autogenerating checkboxes for such plugins on UI is bad, because
explicit is better than implicit (and all our settings are explicitly
defined in openstack.yaml).

On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak wrote:
If there is no checkboxes (read configuration) and plugin is installed - all
deployment tasks will be applied
to every environment, but why do you think that there will be no checkboxes
in most cases?

Right now we already have like 2 types of plugins (extensions), classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara, murano,
zabbix)

In 1st case you need to provide shared configuration storage (like cluster
attributes right now), in order for plugin
to be able to exclude part of core workflow from running (not installing
swift for example).
In case if the plugin is self-contained entity, like Sahara, Murano right
now - checkboxes would be simply required.
It works this way right now, and it doesnot look like huge overhead.

So what do you think, will it work or no?

On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov wrote:

Hi,

Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff for plugins which are not even enabled and do
needless work?

This looks too complicated for me from the backend side, and option
with enabling/disabling plugins in wizard for specific environment (we
can invent mechanism to disable them on env which is not deployed yet,
besides, for API it's just one PUT) is MUCH simpler and much more
obvious, as I see.

On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
wrote:

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 :

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

user installs the plugin
creates a cluster
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

user installs the plugin
now he can choose specific plugins for his environment in wizard
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.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


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

--
Best regards,
Nick Markov

responded Oct 8, 2014 by Nikolay_Markov (1,260 points)   1 2
0 votes

Nikolay,

Currently every thing that can be turned into a plugin (Ceph, vCenter,
Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
controls) for the settings tab. Why change this approach for plugins? The
settings tab (cluster attributes) currently is a SSOT
, and you want to ruin
it for no reason.

Of course it makes no sense to generate anything. Checkboxes on the
settings tab can be added using simple YAML mixin and if you want to check
this checkbox to determine whether to perform some action or not and don't
want to write any python code, try to add to plugin's YAML "restrictions"
section which we already have for the settings tab, the wizard and roles.

2014-10-08 14:50 GMT+07:00 Nikolay Markov :

Right now we already have like 2 types of plugins (extensions),
classified by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
or hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano, zabbix)

That's not quite right. In 6.0 and after that there will be a lot of
small plugins which only modify some config and/or install some
package. There is nothing to configure here, and I as a plugin
developer don't even want to know anything about checkboxes on UI. I
just want two things: role to execute my command on and command
itself. That's one small YAML.

And autogenerating checkboxes for such plugins on UI is bad, because
explicit is better than implicit (and all our settings are explicitly
defined in openstack.yaml).

On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak
wrote:

If there is no checkboxes (read configuration) and plugin is installed -
all
deployment tasks will be applied
to every environment, but why do you think that there will be no
checkboxes
in most cases?

Right now we already have like 2 types of plugins (extensions),
classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano,
zabbix)

In 1st case you need to provide shared configuration storage (like
cluster
attributes right now), in order for plugin
to be able to exclude part of core workflow from running (not installing
swift for example).
In case if the plugin is self-contained entity, like Sahara, Murano right
now - checkboxes would be simply required.
It works this way right now, and it doesnot look like huge overhead.

So what do you think, will it work or no?

On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov
wrote:

Hi,

Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff for plugins which are not even enabled and do
needless work?

This looks too complicated for me from the backend side, and option
with enabling/disabling plugins in wizard for specific environment (we
can invent mechanism to disable them on env which is not deployed yet,
besides, for API it's just one PUT) is MUCH simpler and much more
obvious, as I see.

On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
wrote:

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 :

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

user installs the plugin
creates a cluster
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

user installs the plugin
now he can choose specific plugins for his environment in wizard
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.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


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

--
Best regards,
Nick Markov


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:

responded Oct 8, 2014 by Vitaly_Kramskikh (3,480 points)   2 4
0 votes

Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all
they should do is installing a package and modify a couple of config files
(run a shell command).
These ones have nothing to do with UI or any checkboxes, aren't they?
08 ??? 2014 ?. 12:49 ???????????? "Vitaly Kramskikh" <
vkramskikh at mirantis.com> ???????:

Nikolay,

Currently every thing that can be turned into a plugin (Ceph, vCenter,
Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
controls) for the settings tab. Why change this approach for plugins? The
settings tab (cluster attributes) currently is a SSOT
, and you want to
ruin it for no reason.

Of course it makes no sense to generate anything. Checkboxes on the
settings tab can be added using simple YAML mixin and if you want to check
this checkbox to determine whether to perform some action or not and don't
want to write any python code, try to add to plugin's YAML "restrictions"
section which we already have for the settings tab, the wizard and roles.

2014-10-08 14:50 GMT+07:00 Nikolay Markov :

Right now we already have like 2 types of plugins (extensions),
classified by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
or hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano, zabbix)

That's not quite right. In 6.0 and after that there will be a lot of
small plugins which only modify some config and/or install some
package. There is nothing to configure here, and I as a plugin
developer don't even want to know anything about checkboxes on UI. I
just want two things: role to execute my command on and command
itself. That's one small YAML.

And autogenerating checkboxes for such plugins on UI is bad, because
explicit is better than implicit (and all our settings are explicitly
defined in openstack.yaml).

On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak
wrote:

If there is no checkboxes (read configuration) and plugin is installed
- all
deployment tasks will be applied
to every environment, but why do you think that there will be no
checkboxes
in most cases?

Right now we already have like 2 types of plugins (extensions),
classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano,
zabbix)

In 1st case you need to provide shared configuration storage (like
cluster
attributes right now), in order for plugin
to be able to exclude part of core workflow from running (not installing
swift for example).
In case if the plugin is self-contained entity, like Sahara, Murano
right
now - checkboxes would be simply required.
It works this way right now, and it doesnot look like huge overhead.

So what do you think, will it work or no?

On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov
wrote:

Hi,

Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff for plugins which are not even enabled and do
needless work?

This looks too complicated for me from the backend side, and option
with enabling/disabling plugins in wizard for specific environment (we
can invent mechanism to disable them on env which is not deployed yet,
besides, for API it's just one PUT) is MUCH simpler and much more
obvious, as I see.

On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
wrote:

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 :

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

user installs the plugin
creates a cluster
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

user installs the plugin
now he can choose specific plugins for his environment in wizard
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.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


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

--
Best regards,
Nick Markov


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.


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:

responded Oct 8, 2014 by Nikolay_Markov (1,260 points)   1 2
0 votes

Hi,

Vitaly, I understand your concerns about UX.
But there are technical problems and statements which affect
plugin developer and makes his live more complicated.

My opinion is we definitely should know, if plugin is disabled
or if it's enabled for specific environment.

  1. plugin developer defines tasks, like "I want the script to be
    executed on nodes with controller role" and I don't think that
    he expects this task to be run on all of the nodes, also
    I don't think that we want ask plugin developer to parse
    yaml with bash in order to understand if his plugin is enabled,
    it's a bad design
  2. there will be no way to uninstall the plugin, because all of the
    plugins are enabled on the environments, even if user doesn't
    use them

Also I don't think that it's a good interface, to ask plugin developr
to include checkbox in each plugin.

The second solution is discussed because it's the most explicit
way to solve described problem.

Let's try to figure out the solution which will work well for user
and for plugin developer.

For example, for each plugin generate section on UI with checkbox
Like:

GlusterFS [ ] - disable all of the fields for the section
Here is some description of the section, which we can take from
description field.

IP address [127.0.0.1] - this field provides plugin developer

If plugin is set, we add env <-> plugin relation, if it's unset, we
delete it.
Also when user checks the checkbox, UI will be able to retrieve
attributes which plugin provides. But it's not so easy todo, I'm not
sure if we can do it with hooks, but it's possible with some separate
model and handlers.

Thanks,

On Wed, Oct 8, 2014 at 12:48 PM, Vitaly Kramskikh
wrote:

Nikolay,

Currently every thing that can be turned into a plugin (Ceph, vCenter,
Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
controls) for the settings tab. Why change this approach for plugins? The
settings tab (cluster attributes) currently is a SSOT
, and you want to
ruin it for no reason.

Of course it makes no sense to generate anything. Checkboxes on the
settings tab can be added using simple YAML mixin and if you want to check
this checkbox to determine whether to perform some action or not and don't
want to write any python code, try to add to plugin's YAML "restrictions"
section which we already have for the settings tab, the wizard and roles.

2014-10-08 14:50 GMT+07:00 Nikolay Markov :

Right now we already have like 2 types of plugins (extensions),
classified by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
or hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano, zabbix)

That's not quite right. In 6.0 and after that there will be a lot of
small plugins which only modify some config and/or install some
package. There is nothing to configure here, and I as a plugin
developer don't even want to know anything about checkboxes on UI. I
just want two things: role to execute my command on and command
itself. That's one small YAML.

And autogenerating checkboxes for such plugins on UI is bad, because
explicit is better than implicit (and all our settings are explicitly
defined in openstack.yaml).

On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak
wrote:

If there is no checkboxes (read configuration) and plugin is installed
- all
deployment tasks will be applied
to every environment, but why do you think that there will be no
checkboxes
in most cases?

Right now we already have like 2 types of plugins (extensions),
classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano,
zabbix)

In 1st case you need to provide shared configuration storage (like
cluster
attributes right now), in order for plugin
to be able to exclude part of core workflow from running (not installing
swift for example).
In case if the plugin is self-contained entity, like Sahara, Murano
right
now - checkboxes would be simply required.
It works this way right now, and it doesnot look like huge overhead.

So what do you think, will it work or no?

On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov
wrote:

Hi,

Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff for plugins which are not even enabled and do
needless work?

This looks too complicated for me from the backend side, and option
with enabling/disabling plugins in wizard for specific environment (we
can invent mechanism to disable them on env which is not deployed yet,
besides, for API it's just one PUT) is MUCH simpler and much more
obvious, as I see.

On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
wrote:

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 :

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

user installs the plugin
creates a cluster
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

user installs the plugin
now he can choose specific plugins for his environment in wizard
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.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


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

--
Best regards,
Nick Markov


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.


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:

responded Oct 8, 2014 by Evgeniy_L (8,580 points)   1 2 4
0 votes

So they should be implemented like Murano or Sahara and provide a checkbox
in "Additional Services" section of the settings tab and the wizard

2014-10-08 19:57 GMT+07:00 Nikolay Markov :

Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all
they should do is installing a package and modify a couple of config files
(run a shell command).
These ones have nothing to do with UI or any checkboxes, aren't they?
08 ??? 2014 ?. 12:49 ???????????? "Vitaly Kramskikh" <
vkramskikh at mirantis.com> ???????:

Nikolay,

Currently every thing that can be turned into a plugin (Ceph, vCenter,
Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
controls) for the settings tab. Why change this approach for plugins? The
settings tab (cluster attributes) currently is a SSOT
, and you want to
ruin it for no reason.

Of course it makes no sense to generate anything. Checkboxes on the
settings tab can be added using simple YAML mixin and if you want to check
this checkbox to determine whether to perform some action or not and don't
want to write any python code, try to add to plugin's YAML "restrictions"
section which we already have for the settings tab, the wizard and roles.

2014-10-08 14:50 GMT+07:00 Nikolay Markov :

Right now we already have like 2 types of plugins (extensions),
classified by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),
or hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano, zabbix)

That's not quite right. In 6.0 and after that there will be a lot of
small plugins which only modify some config and/or install some
package. There is nothing to configure here, and I as a plugin
developer don't even want to know anything about checkboxes on UI. I
just want two things: role to execute my command on and command
itself. That's one small YAML.

And autogenerating checkboxes for such plugins on UI is bad, because
explicit is better than implicit (and all our settings are explicitly
defined in openstack.yaml).

On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak
wrote:

If there is no checkboxes (read configuration) and plugin is installed
- all
deployment tasks will be applied
to every environment, but why do you think that there will be no
checkboxes
in most cases?

Right now we already have like 2 types of plugins (extensions),
classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara,
murano,
zabbix)

In 1st case you need to provide shared configuration storage (like
cluster
attributes right now), in order for plugin
to be able to exclude part of core workflow from running (not
installing
swift for example).
In case if the plugin is self-contained entity, like Sahara, Murano
right
now - checkboxes would be simply required.
It works this way right now, and it doesnot look like huge overhead.

So what do you think, will it work or no?

On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov
wrote:

Hi,

Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff for plugins which are not even enabled and do
needless work?

This looks too complicated for me from the backend side, and option
with enabling/disabling plugins in wizard for specific environment (we
can invent mechanism to disable them on env which is not deployed yet,
besides, for API it's just one PUT) is MUCH simpler and much more
obvious, as I see.

On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
wrote:

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 :

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

user installs the plugin
creates a cluster
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

user installs the plugin
now he can choose specific plugins for his environment in wizard
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.


OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


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

--
Best regards,
Nick Markov


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.


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

--
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Oct 8, 2014 by Vitaly_Kramskikh (3,480 points)   2 4
...