Open Stack

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 <nmarkov at mirantis.com> 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
> <vkramskikh at mirantis.com> 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 <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
> >>
> >> 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: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141008/7ca9fd1f/attachment.html>