Open Stack

Thanks, good.

On Wed, Oct 15, 2014 at 12:41 PM, Evgeniy L <eli at mirantis.com> wrote:

> Hi Mike,
>
> Dmitry S. started to work on checkboxes auto-generation in nailgun
> for UI.
> And in parallel I've written simple script which just updates release
> model with checkboxes and plugin's fields, this simple script will be used
> only for POC, and then we will replace it with Dmitry's implementation when
> it's ready.
>
> Thanks,
>
> On Tue, Oct 14, 2014 at 10:50 PM, Mike Scherbakov <
> mscherbakov at mirantis.com> wrote:
>
>> +1 for doing now:
>> > we are going to implement something really simple, like updating
>> plugin attributes directly via api.
>> Then we can have discussions in parallel how we plan to evolve it.
>>
>> Please confirm that we went this path.
>>
>> Thanks,
>>
>>
>> On Mon, Oct 13, 2014 at 7:31 PM, Evgeniy L <eli at mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> We've discussed what we will be able to do for the current release and
>>> what we will not be able to implement.
>>> We have not only technical problems, but also we don't have a lot of time
>>> for implementation. We were trying to find solution which will work well
>>> enough
>>> with all of the constraints.
>>> For the current release we want to implement approach which was suggested
>>> by Mike.
>>> We are going to generate for UI checkbox which defines if plugin is set
>>> for
>>> deployment. In nailgun we'll be able to parse generated checkboxes and
>>> remove or add relation between plugin and cluster models.
>>> With this relation we'll be able to identify if plugins is used, it will
>>> allow us
>>> to remove the plugins if it's unused (in the future), or if we need to
>>> pass
>>> tasks to orchestrator. Also in POC, we are going to implement something
>>> really simple, like updating plugin attributes directly via api.
>>>
>>> Thanks,
>>>
>>> On Thu, Oct 9, 2014 at 8:13 PM, Dmitry Borodaenko <
>>> dborodaenko at mirantis.com> wrote:
>>>
>>>> Notes from the architecture review meeting on plugins UX:
>>>>
>>>>    - separate page for plugins management
>>>>    - user installs the plugin on the master
>>>>    - global master node configuration across all environments:
>>>>       - user can see a list of plugins on Plugins tab (plugins
>>>>       description)
>>>>       - Enable/Disable plugin
>>>>          - should we enable/disable plugins globally, or only per
>>>>          environment?
>>>>             - yes, we need a global plugins management page, it will
>>>>             later be extended to upload or remove plugins
>>>>          - if a plugin is used in a deployed environment, options to
>>>>          globally disable or remove that plugin are blocked
>>>>       - show which environments (or a number of environments) have a
>>>>       specific plugin enabled
>>>>       - global plugins page is a Should in 6.0 (but easy to add)
>>>>       - future: a plugin like ostf should have a deployable flag set
>>>>       to false, so that it doesn't show up as an option per env
>>>>    - user creates new environment
>>>>       - in setup wizard on the releases page (1st step), a list of
>>>>       checkboxes for all plugins is offered (same page as releases?)
>>>>          - all globally enabled plugins are checked (enabled) by
>>>>          default
>>>>          - changes in selection of plugins will trigger regeneration
>>>>          of subsequent setup wizard steps
>>>>       - plugin may include a yaml mixin for settings page options in
>>>>       openstack.yaml format
>>>>          - in future releases, it will support describing setup wizard
>>>>          (disk configuration, network settings etc.) options in the same way
>>>>          - what is the simplest case? does plugin writer have to
>>>>          define the plugin enable/disable checkbox, or is it autogenerated?
>>>>             - if plugin does not define any configuration options: a
>>>>             checkbox is automatically added into Additional Services section of the
>>>>             settings page (disabled by default)
>>>>             - *problem:* if a plugin is enabled by default, but the
>>>>             option to deploy it is disabled by default, such environment would count
>>>>             against the plugin (and won't allow to remove this plugin globally) even
>>>>             though it actually wasn't deployed
>>>>          - manifest of plugins enabled/used for an environment?
>>>>
>>>>
>>>> We ended the discussion on the problem highlighted in bold above:
>>>> what's the best way to detect which plugins are actually used in an
>>>> environment?
>>>>
>>>>
>>>> On Thu, Oct 9, 2014 at 6:42 AM, Vitaly Kramskikh <
>>>> vkramskikh at mirantis.com> wrote:
>>>>
>>>>> Evgeniy,
>>>>>
>>>>> Yes, the plugin management page should be a separate page. As for
>>>>> dependency on releases, I meant that some plugin can work only on Ubuntu
>>>>> for example, so for different releases different plugins could be available.
>>>>>
>>>>> And please confirm that you also agree with the flow: the user install
>>>>> a plugin, then he enables it on the plugin management page, and then he
>>>>> creates an environment and on the first step he can uncheck some plugins
>>>>> which he doesn't want to use in that particular environment.
>>>>>
>>>>> 2014-10-09 20:11 GMT+07:00 Evgeniy L <eli at mirantis.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Vitaly, I like the idea of having separate page, but I'm not sure if
>>>>>> it should be on releases page.
>>>>>> Usually a plugin is not release specific, usually it's environment
>>>>>> specific and you can have
>>>>>> different set of plugins for different environments.
>>>>>>
>>>>>> Also I don't think that we should enable plugins by default, user
>>>>>> should enable plugin if he wants
>>>>>> it to be installed.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> On Thu, Oct 9, 2014 at 3:34 PM, Vitaly Kramskikh <
>>>>>> vkramskikh at mirantis.com> wrote:
>>>>>>
>>>>>>> Let me propose another approach. I agree with most of Dmitry's
>>>>>>> statements and it seems in MVP we need plugin management UI where we can
>>>>>>> enable installed plugins. It should be a separate page. If you want to
>>>>>>> create environment with a plugin, enable the plugin on this page and create
>>>>>>> a new environment. You can also disable and uninstall plugins using that
>>>>>>> page (if there is no environments with the plugin enabled).
>>>>>>>
>>>>>>> The main reason why I'm against Evgeniy's 2nd approach (explicitly
>>>>>>> enabling plugins in the wizard) is that we need to add a step where we
>>>>>>> choose the plugins. This step should be added right after choice of
>>>>>>> environment name and release, because options on the next steps and even
>>>>>>> steps could be added from plugins. And this is complete disaster for UX.
>>>>>>> Imagine a new user which uses Fuel for the first time and has to decide
>>>>>>> which plugins he will use right after giving a name to an environment.
>>>>>>>
>>>>>>> So I think if we implement plugin management page and make user
>>>>>>> explicitly and globally enable installed plugins there we can implement
>>>>>>> Evgeniy's 2nd approach, but in a slightly different way. I think we need to
>>>>>>> use all enabled plugins for new environments by default and let user to
>>>>>>> uncheck some of them, so they won't be used for that particular
>>>>>>> environment. I think the checkboxes should be right on the first pane under
>>>>>>> release selectbox (it makes sense because different releases could have
>>>>>>> different plugins available). These checkboxes should be hidden by default
>>>>>>> and only appear after user clicks a button named like "customize used
>>>>>>> plugins". I think we should use the word "use" here instead of "enable" as
>>>>>>> we "enable" plugins on the plugin management page.
>>>>>>>
>>>>>>> The plugin management page and explicit enabling of plugins are also
>>>>>>> required for plugins with an UI part as we need to preload it when UI loads
>>>>>>> and not when the wizard opens as the plugin can contain mixins for the
>>>>>>> wizard.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> 2014-10-09 11:04 GMT+07:00 Dmitry Borodaenko <
>>>>>>> dborodaenko at mirantis.com>:
>>>>>>>
>>>>>>>> I don't like how this discussion is framed. The initial premise
>>>>>>>> that we have
>>>>>>>> only two controversial options to choose from is lazy. If there is
>>>>>>>> no
>>>>>>>> consensus, we should look for more options, not for a popular vote.
>>>>>>>>
>>>>>>>> Secondly, current level of UX is not negotiable. You can't take
>>>>>>>> something that
>>>>>>>> we already have and that works (and current Fuel UI is the best out
>>>>>>>> there by a
>>>>>>>> wide margin), and make it worse just to add a new feature. Even
>>>>>>>> something as
>>>>>>>> important as plugins must be an incremental improvement.
>>>>>>>>
>>>>>>>> With that premise, lets decompose the problem.
>>>>>>>>
>>>>>>>> 1. There are two levels of settings related to any plugin: a) first
>>>>>>>> you have to
>>>>>>>> enable enable the plugin itself; b) when the plugin is enabled, it
>>>>>>>> may expose
>>>>>>>> additional settings.
>>>>>>>>
>>>>>>>> - How can it be acceptable to have all plugins always enabled in all
>>>>>>>>   environments? Do you really trust all plugin writers to carefully
>>>>>>>> check for
>>>>>>>>   plugin-specific options and ensure there is zero impact on an
>>>>>>>> environment if
>>>>>>>>   none of its options are enabled?
>>>>>>>>
>>>>>>>> - If all your plugins are enabled everywhere, you can't uninstall
>>>>>>>> any of them
>>>>>>>>   because all environments you deployed would become unmanageable.
>>>>>>>>
>>>>>>>> - If you ignore uninstallation, soon you will be stuck with plugins
>>>>>>>> that cannot
>>>>>>>>   be made removable even when Fuel itself begins to support it.
>>>>>>>>
>>>>>>>> - To break away from unremovable plugins, you're likely going to
>>>>>>>> have to break
>>>>>>>>   backwards compatibility (unless you already have a
>>>>>>>> forward-compatible design
>>>>>>>>   that allows for removable plugins in the future, but then you
>>>>>>>> wouldn't have
>>>>>>>>   to exclude removing plugins from MVP).
>>>>>>>>
>>>>>>>> - And if a Fuel upgrade ever requires uninstalling a plugin due to
>>>>>>>>   irreconcilable incompatibility, and they're enabled in all of your
>>>>>>>>   environments, you're stuck unable to upgrade.
>>>>>>>>
>>>>>>>> So, lets not enable any plugins by default. And if we can come up
>>>>>>>> with a way to
>>>>>>>> make them removable (when they're not enabled in any deployed
>>>>>>>> environments), we
>>>>>>>> should at least leave room for that in the design.
>>>>>>>>
>>>>>>>> 2. Either level of plugin settings (enable or configure) may be
>>>>>>>> exposed in
>>>>>>>> setup wizard, settings page, or both.
>>>>>>>>
>>>>>>>> - Yes, additional plugin settings also may show up in the wizard
>>>>>>>> (e.g. vCenter
>>>>>>>>   credentials).
>>>>>>>>
>>>>>>>> - Yes, we should maintain the settings page as the SSoT, and that
>>>>>>>> means
>>>>>>>>   reflecting as many of setup wizard options in it as possible.
>>>>>>>>
>>>>>>>> - Yes, for some options (like choice of operating system or network
>>>>>>>> topology),
>>>>>>>>   our settings page is not dynamic enough to allow user to go back
>>>>>>>> and revert
>>>>>>>>   them without recreating the environment.
>>>>>>>>
>>>>>>>> - No, plugin writer shouldn't have to explicitly describe a
>>>>>>>> checkbox to enable
>>>>>>>>   their plugin. They only should provide name and description of
>>>>>>>> the plugin.
>>>>>>>>   Plugin engine should be able to produce a catalogue of installed
>>>>>>>> plugins, and
>>>>>>>>   UI should generate enable checkboxes from that catalogue.
>>>>>>>>
>>>>>>>> - If a plugin doesn't affect any available environment
>>>>>>>> configuration options
>>>>>>>>   outside of the settings tab (i.e. setup wizard, network settings,
>>>>>>>> node roles,
>>>>>>>>   disk & nic configuration), there's no reason to limit it to setup
>>>>>>>> wizard, the
>>>>>>>>   "enable" checkbox and whatever other options it has should all be
>>>>>>>> present in
>>>>>>>>   the settings page.
>>>>>>>>
>>>>>>>> - Do we have any plugins in 6.0 that have to be present in setup
>>>>>>>> wizard because
>>>>>>>>   they affect UI outside of settings page? I'm not aware of any.
>>>>>>>>
>>>>>>>> If so, lets start by representing all plugin settings in the
>>>>>>>> settings page. But
>>>>>>>> leave the room in the metadata to force some or all of plugin's
>>>>>>>> settings to
>>>>>>>> show up in the setup wizard (or even to present plugin
>>>>>>>> configuration options
>>>>>>>> differently in the wizard than in the settings).
>>>>>>>>
>>>>>>>> Just my $2,
>>>>>>>> -DmitryB
>>>>>>>>
>>>>>>>> On Wed, Oct 8, 2014 at 9:18 AM, Nikolay Markov <
>>>>>>>> nmarkov at mirantis.com> wrote:
>>>>>>>> > Vitaly,
>>>>>>>> >
>>>>>>>> > Once again, as a plugin developer I don't care about how Sahara
>>>>>>>> or Murano is
>>>>>>>> > implemented. I don't care about checkboxes, either. I just want
>>>>>>>> one simple
>>>>>>>> > command to run on target nodes and I should be provided with the
>>>>>>>> simplest
>>>>>>>> > possible interface to:
>>>>>>>> > 1) Write this command in some YAML and don't care about anything
>>>>>>>> else
>>>>>>>> > 2) Enable my plugin for particular environment and see if it's
>>>>>>>> really
>>>>>>>> > enabled both on UI and CLI (and through pure API by simple field
>>>>>>>> checking)
>>>>>>>> >
>>>>>>>> > If it provides some separate service - this doesn't change
>>>>>>>> anything, I just
>>>>>>>> > need it to be listed somewhere in "plugins" inside cluster data
>>>>>>>> to know that
>>>>>>>> > it'll be executed.
>>>>>>>> >
>>>>>>>> > How will it work with your approach?
>>>>>>>> >
>>>>>>>> > 08 Окт 2014 г. 20:00 пользователь "Vitaly Kramskikh"
>>>>>>>> > <vkramskikh at mirantis.com> написал:
>>>>>>>> >
>>>>>>>> >> 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, 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.
>>>>>>>> >>
>>>>>>>> >> _______________________________________________
>>>>>>>> >> 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
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dmitry Borodaenko
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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.
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Dmitry Borodaenko
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141015/44fe15aa/attachment.html>