Open Stack

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
> <http://en.wikipedia.org/wiki/Single_Source_of_Truth>, 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 <nmarkov at mirantis.com>:
>
>> >>> 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 <dshulyak at mirantis.com>
>> 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 <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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141008/f6c02b32/attachment.html>