Thanks, good. On Wed, Oct 15, 2014 at 12:41 PM, Evgeniy L <e...@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 < > mscherba...@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 <e...@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 < >>> dborodae...@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 < >>>> vkramsk...@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 <e...@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 < >>>>>> vkramsk...@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 < >>>>>>> dborodae...@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 < >>>>>>>> nmar...@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" >>>>>>>> > <vkramsk...@mirantis.com> написал: >>>>>>>> > >>>>>>>> >> Hi, responses inline. >>>>>>>> >> >>>>>>>> >> 2014-10-08 21:09 GMT+07:00 Evgeniy L <e...@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 >>>>>>>> >>> <vkramsk...@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 < >>>>>>>> nmar...@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 >>>>>>>> >>>>> <dshul...@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 < >>>>>>>> nmar...@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 >>>>>>>> >>>>> >> <vkramsk...@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 <e...@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@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@lists.openstack.org >>>>>>>> >>>>> >> > >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>> >> > >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> -- >>>>>>>> >>>>> >> Best regards, >>>>>>>> >>>>> >> Nick Markov >>>>>>>> >>>>> >> >>>>>>>> >>>>> >> _______________________________________________ >>>>>>>> >>>>> >> OpenStack-dev mailing list >>>>>>>> >>>>> >> OpenStack-dev@lists.openstack.org >>>>>>>> >>>>> >> >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>> > >>>>>>>> >>>>> > >>>>>>>> >>>>> > >>>>>>>> >>>>> > _______________________________________________ >>>>>>>> >>>>> > OpenStack-dev mailing list >>>>>>>> >>>>> > OpenStack-dev@lists.openstack.org >>>>>>>> >>>>> > >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>> > >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> -- >>>>>>>> >>>>> Best regards, >>>>>>>> >>>>> Nick Markov >>>>>>>> >>>>> >>>>>>>> >>>>> _______________________________________________ >>>>>>>> >>>>> OpenStack-dev mailing list >>>>>>>> >>>>> OpenStack-dev@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@lists.openstack.org >>>>>>>> >>>> >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> _______________________________________________ >>>>>>>> >>> OpenStack-dev mailing list >>>>>>>> >>> OpenStack-dev@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@lists.openstack.org >>>>>>>> >> >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >> >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > OpenStack-dev mailing list >>>>>>>> > OpenStack-dev@lists.openstack.org >>>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Borodaenko >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenStack-dev mailing list >>>>>>>> OpenStack-dev@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@lists.openstack.org >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@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@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dmitry Borodaenko >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Mike Scherbakov >> #mihgen >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Mike Scherbakov #mihgen
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
