Open Stack

Hi, responses inline.

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

> 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
>
Bash script shouldn't be even run if the conditions to run it are not met.
I described above how it could be done.

> 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
>
Well, this is the only issue that I see with the first approach and I still
don't know how to solve it.

> Also I don't think that it's a good interface, to ask plugin developr
> to include checkbox in each plugin.
>
> It should be included only in plugins which affect the installation. For
example, if OSTF was a plugin it wouldn't need such a checkbox. We can also
make kind of plugin bootstrap or a sample plugin whcih will include a
single control.

> 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:
>
Well, first Nikolay disliked need for a checkbox for any plugin and now you
want to autogenerate a section. Why woudn't we give plugin writers ability
to describe the controls themselves? For example, LBaaS would require a
single checkbox in "Additional Services" section.

>
> 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 <vkramskikh at mirantis.com
> > 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
>> <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
>>
>>
>
> _______________________________________________
> 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/c616cb21/attachment.html>