<div dir="ltr">Hi Mike,<div><br></div><div>Dmitry S. started to work on checkboxes auto-generation in nailgun</div><div>for UI.</div><div>And in parallel I've written simple script which just updates release</div><div>model with checkboxes and plugin's fields, this simple script will be used</div><div>only for POC, and then we will replace it with Dmitry's implementation when</div><div>it's ready.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 14, 2014 at 10:50 PM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+1 for doing now:<span class=""><div>> <span style="font-family:arial,sans-serif;font-size:12.8000001907349px">we are going to implement something </span><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">really simple, like updating plugin attributes directly via api.</span></div></span><div><span style="font-family:arial,sans-serif">Then we can have discussions in parallel how we plan to evolve it.</span><br></div><div><span style="font-family:arial,sans-serif"><br>Please confirm that we went this path.</span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">Thanks,</span></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 7:31 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>We've discussed what we will be able to do for the current release and</div><div>what we will not be able to implement.</div><div>We have not only technical problems, but also we don't have a lot of time</div><div>for implementation. We were trying to find solution which will work well enough</div><div>with all of the constraints.</div><div>For the current release we want to implement approach which was suggested<br></div><div>by Mike.</div><div>We are going to generate for UI checkbox which defines if plugin is set for</div><div>deployment. In nailgun we'll be able to parse generated checkboxes and</div><div>remove or add relation between plugin and cluster models.</div><div>With this relation we'll be able to identify if plugins is used, it will allow us</div><div>to remove the plugins if it's unused (in the future), or if we need to pass</div><div>tasks to orchestrator. Also in POC, we are going to implement something</div><div>really simple, like updating plugin attributes directly via api.</div><div><br></div><div>Thanks,</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 8:13 PM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Notes from the architecture review meeting on plugins UX:<br><ul><li>separate page for plugins management</li><li>user installs the plugin on the master</li><li>global master node configuration across all environments:<ul><li>user can see a list of plugins on Plugins tab (plugins description)</li><li>Enable/Disable plugin<ul><li>should we enable/disable plugins globally, or only per environment?<ul><li>yes, we need a global plugins management page, it will later be extended to upload or remove plugins</li></ul></li><li>if a plugin is used in a deployed environment, options to globally disable or remove that plugin are blocked</li></ul></li><li>show which environments (or a number of environments) have a specific plugin enabled</li><li>global plugins page is a Should in 6.0 (but easy to add)</li><li>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</li></ul></li><li>user creates new environment<ul><li>in setup wizard on the releases page (1st step), a list of checkboxes for all plugins is offered (same page as releases?)<ul><li>all globally enabled plugins are checked (enabled) by default</li><li>changes in selection of plugins will trigger regeneration of subsequent setup wizard steps</li></ul></li><li>plugin may include a yaml mixin for settings page options in openstack.yaml format<ul><li>in future releases, it will support describing setup wizard (disk configuration, network settings etc.) options in the same way</li><li>what is the simplest case? does plugin writer have to define the plugin enable/disable checkbox, or is it autogenerated?<ul><li>if
plugin does not define any configuration options: a checkbox is
automatically added into Additional Services section of the settings
page (disabled by default)</li><li><strong>problem:</strong> 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</li></ul></li></ul></li><li>manifest of plugins enabled/used for an environment?</li></ul></li></ul><br></div>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?<br><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 6:42 AM, Vitaly Kramskikh <span dir="ltr"><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Evgeniy,<br><br></div>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.<br><br></div>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.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-09 20:11 GMT+07:00 Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Vitaly, I like the idea of having separate page, but I'm not sure if it should be on releases page.<br></div><div>Usually a plugin is not release specific, usually it's environment specific and you can have</div><div>different set of plugins for different environments.</div><div><br></div><div>Also I don't think that we should enable plugins by default, user should enable plugin if he wants</div><div>it to be installed.</div><div><br></div><div>Thanks,</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 3:34 PM, Vitaly Kramskikh <span dir="ltr"><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>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).<br><br></div>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.<br><br></div>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.<br><br></div>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.<br><br></div>What do you think?<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-09 11:04 GMT+07:00 Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't like how this discussion is framed. The initial premise that we have<br>
only two controversial options to choose from is lazy. If there is no<br>
consensus, we should look for more options, not for a popular vote.<br>
<br>
Secondly, current level of UX is not negotiable. You can't take something that<br>
we already have and that works (and current Fuel UI is the best out there by a<br>
wide margin), and make it worse just to add a new feature. Even something as<br>
important as plugins must be an incremental improvement.<br>
<br>
With that premise, lets decompose the problem.<br>
<br>
1. There are two levels of settings related to any plugin: a) first you have to<br>
enable enable the plugin itself; b) when the plugin is enabled, it may expose<br>
additional settings.<br>
<br>
- How can it be acceptable to have all plugins always enabled in all<br>
environments? Do you really trust all plugin writers to carefully check for<br>
plugin-specific options and ensure there is zero impact on an environment if<br>
none of its options are enabled?<br>
<br>
- If all your plugins are enabled everywhere, you can't uninstall any of them<br>
because all environments you deployed would become unmanageable.<br>
<br>
- If you ignore uninstallation, soon you will be stuck with plugins that cannot<br>
be made removable even when Fuel itself begins to support it.<br>
<br>
- To break away from unremovable plugins, you're likely going to have to break<br>
backwards compatibility (unless you already have a forward-compatible design<br>
that allows for removable plugins in the future, but then you wouldn't have<br>
to exclude removing plugins from MVP).<br>
<br>
- And if a Fuel upgrade ever requires uninstalling a plugin due to<br>
irreconcilable incompatibility, and they're enabled in all of your<br>
environments, you're stuck unable to upgrade.<br>
<br>
So, lets not enable any plugins by default. And if we can come up with a way to<br>
make them removable (when they're not enabled in any deployed environments), we<br>
should at least leave room for that in the design.<br>
<br>
2. Either level of plugin settings (enable or configure) may be exposed in<br>
setup wizard, settings page, or both.<br>
<br>
- Yes, additional plugin settings also may show up in the wizard (e.g. vCenter<br>
credentials).<br>
<br>
- Yes, we should maintain the settings page as the SSoT, and that means<br>
reflecting as many of setup wizard options in it as possible.<br>
<br>
- Yes, for some options (like choice of operating system or network topology),<br>
our settings page is not dynamic enough to allow user to go back and revert<br>
them without recreating the environment.<br>
<br>
- No, plugin writer shouldn't have to explicitly describe a checkbox to enable<br>
their plugin. They only should provide name and description of the plugin.<br>
Plugin engine should be able to produce a catalogue of installed plugins, and<br>
UI should generate enable checkboxes from that catalogue.<br>
<br>
- If a plugin doesn't affect any available environment configuration options<br>
outside of the settings tab (i.e. setup wizard, network settings, node roles,<br>
disk & nic configuration), there's no reason to limit it to setup wizard, the<br>
"enable" checkbox and whatever other options it has should all be present in<br>
the settings page.<br>
<br>
- Do we have any plugins in 6.0 that have to be present in setup wizard because<br>
they affect UI outside of settings page? I'm not aware of any.<br>
<br>
If so, lets start by representing all plugin settings in the settings page. But<br>
leave the room in the metadata to force some or all of plugin's settings to<br>
show up in the setup wizard (or even to present plugin configuration options<br>
differently in the wizard than in the settings).<br>
<br>
Just my $2,<br>
-DmitryB<br>
<div><div><br>
On Wed, Oct 8, 2014 at 9:18 AM, Nikolay Markov <<a href="mailto:nmarkov@mirantis.com" target="_blank">nmarkov@mirantis.com</a>> wrote:<br>
> Vitaly,<br>
><br>
> Once again, as a plugin developer I don't care about how Sahara or Murano is<br>
> implemented. I don't care about checkboxes, either. I just want one simple<br>
> command to run on target nodes and I should be provided with the simplest<br>
> possible interface to:<br>
> 1) Write this command in some YAML and don't care about anything else<br>
> 2) Enable my plugin for particular environment and see if it's really<br>
> enabled both on UI and CLI (and through pure API by simple field checking)<br>
><br>
> If it provides some separate service - this doesn't change anything, I just<br>
> need it to be listed somewhere in "plugins" inside cluster data to know that<br>
> it'll be executed.<br>
><br>
> How will it work with your approach?<br>
><br>
> 08 Окт 2014 г. 20:00 пользователь "Vitaly Kramskikh"<br>
> <<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>> написал:<br>
><br>
>> Hi, responses inline.<br>
>><br>
>> 2014-10-08 21:09 GMT+07:00 Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>>:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> Vitaly, I understand your concerns about UX.<br>
>>> But there are technical problems and statements which affect<br>
>>> plugin developer and makes his live more complicated.<br>
>>><br>
>>> My opinion is we definitely should know, if plugin is disabled<br>
>>> or if it's enabled for specific environment.<br>
>>><br>
>>> 1. plugin developer defines tasks, like "I want the script to be<br>
>>> executed on nodes with controller role" and I don't think that<br>
>>> he expects this task to be run on all of the nodes, also<br>
>>> I don't think that we want ask plugin developer to parse<br>
>>> yaml with bash in order to understand if his plugin is enabled,<br>
>>> it's a bad design<br>
>><br>
>> Bash script shouldn't be even run if the conditions to run it are not met.<br>
>> I described above how it could be done.<br>
>>><br>
>>> 2. there will be no way to uninstall the plugin, because all of the<br>
>>> plugins are enabled on the environments, even if user doesn't<br>
>>> use them<br>
>><br>
>> Well, this is the only issue that I see with the first approach and I<br>
>> still don't know how to solve it.<br>
>>><br>
>>> Also I don't think that it's a good interface, to ask plugin developr<br>
>>> to include checkbox in each plugin.<br>
>>><br>
>> It should be included only in plugins which affect the installation. For<br>
>> example, if OSTF was a plugin it wouldn't need such a checkbox. We can also<br>
>> make kind of plugin bootstrap or a sample plugin whcih will include a single<br>
>> control.<br>
>>><br>
>>> The second solution is discussed because it's the most explicit<br>
>>> way to solve described problem.<br>
>>><br>
>>> Let's try to figure out the solution which will work well for user<br>
>>> and for plugin developer.<br>
>>><br>
>>> For example, for each plugin generate section on UI with checkbox<br>
>>> Like:<br>
>><br>
>> Well, first Nikolay disliked need for a checkbox for any plugin and now<br>
>> you want to autogenerate a section. Why woudn't we give plugin writers<br>
>> ability to describe the controls themselves? For example, LBaaS would<br>
>> require a single checkbox in "Additional Services" section.<br>
>>><br>
>>><br>
>>> GlusterFS [ ] - disable all of the fields for the section<br>
>>> Here is some description of the section, which we can take from<br>
>>> description field.<br>
>>><br>
>>> IP address [127.0.0.1] - this field provides plugin developer<br>
>>><br>
>>> If plugin is set, we add env <-> plugin relation, if it's unset, we<br>
>>> delete it.<br>
>>> Also when user checks the checkbox, UI will be able to retrieve<br>
>>> attributes which plugin provides. But it's not so easy todo, I'm not<br>
>>> sure if we can do it with hooks, but it's possible with some separate<br>
>>> model and handlers.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> On Wed, Oct 8, 2014 at 12:48 PM, Vitaly Kramskikh<br>
>>> <<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>> wrote:<br>
>>>><br>
>>>> Nikolay,<br>
>>>><br>
>>>> Currently every thing that can be turned into a plugin (Ceph, vCenter,<br>
>>>> Sahara, Murano, Ceilometer) provides a checkbox (or more complicated<br>
>>>> controls) for the settings tab. Why change this approach for plugins? The<br>
>>>> settings tab (cluster attributes) currently is a SSOT, and you want to ruin<br>
>>>> it for no reason.<br>
>>>><br>
>>>> Of course it makes no sense to generate anything. Checkboxes on the<br>
>>>> settings tab can be added using simple YAML mixin and if you want to check<br>
>>>> this checkbox to determine whether to perform some action or not and don't<br>
>>>> want to write any python code, try to add to plugin's YAML "restrictions"<br>
>>>> section which we already have for the settings tab, the wizard and roles.<br>
>>>><br>
>>>> 2014-10-08 14:50 GMT+07:00 Nikolay Markov <<a href="mailto:nmarkov@mirantis.com" target="_blank">nmarkov@mirantis.com</a>>:<br>
>>>>><br>
>>>>> >>> Right now we already have like 2 types of plugins (extensions),<br>
>>>>> >>> classified by usage of settings tab:<br>
>>>>> >>> 1. Some kind of backend for service (swift/ceph, lvm/ceph,<br>
>>>>> >>> ovs/nsx), or hypervisor (lvm/qemu/vmware)<br>
>>>>> >>> 2. Self-contained service that just needs to be installed (sahara,<br>
>>>>> >>> murano, zabbix)<br>
>>>>><br>
>>>>> That's not quite right. In 6.0 and after that there will be a lot of<br>
>>>>> small plugins which only modify some config and/or install some<br>
>>>>> package. There is nothing to configure here, and I as a plugin<br>
>>>>> developer don't even want to know anything about checkboxes on UI. I<br>
>>>>> just want two things: role to execute my command on and command<br>
>>>>> itself. That's one small YAML.<br>
>>>>><br>
>>>>> And autogenerating checkboxes for such plugins on UI is bad, because<br>
>>>>> explicit is better than implicit (and all our settings are explicitly<br>
>>>>> defined in openstack.yaml).<br>
>>>>><br>
>>>>> On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak<br>
>>>>> <<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>> wrote:<br>
>>>>> > If there is no checkboxes (read configuration) and plugin is<br>
>>>>> > installed - all<br>
>>>>> > deployment tasks will be applied<br>
>>>>> > to every environment, but why do you think that there will be no<br>
>>>>> > checkboxes<br>
>>>>> > in most cases?<br>
>>>>> ><br>
>>>>> > Right now we already have like 2 types of plugins (extensions),<br>
>>>>> > classified<br>
>>>>> > by usage of settings tab:<br>
>>>>> > 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx),<br>
>>>>> > or<br>
>>>>> > hypervisor (lvm/qemu/vmware)<br>
>>>>> > 2. Self-contained service that just needs to be installed (sahara,<br>
>>>>> > murano,<br>
>>>>> > zabbix)<br>
>>>>> ><br>
>>>>> > In 1st case you need to provide shared configuration storage (like<br>
>>>>> > cluster<br>
>>>>> > attributes right now), in order for plugin<br>
>>>>> > to be able to exclude part of core workflow from running (not<br>
>>>>> > installing<br>
>>>>> > swift for example).<br>
>>>>> > In case if the plugin is self-contained entity, like Sahara, Murano<br>
>>>>> > right<br>
>>>>> > now - checkboxes would be simply required.<br>
>>>>> > It works this way right now, and it doesnot look like huge overhead.<br>
>>>>> ><br>
>>>>> > So what do you think, will it work or no?<br>
>>>>> ><br>
>>>>> > On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov <<a href="mailto:nmarkov@mirantis.com" target="_blank">nmarkov@mirantis.com</a>><br>
>>>>> > wrote:<br>
>>>>> >><br>
>>>>> >> Hi,<br>
>>>>> >><br>
>>>>> >> Frankly speaking, I'm not sure on how 1st approach will even work.<br>
>>>>> >> What if plugin doesn't provide any checkboxes (and in most cases it<br>
>>>>> >> won't)? How should we determine in serializer, which plugins should<br>
>>>>> >> be<br>
>>>>> >> applied while generating astute.yaml and tasks.yaml? Should we<br>
>>>>> >> autogenerate some stuff for plugins which are not even enabled and<br>
>>>>> >> do<br>
>>>>> >> needless work?<br>
>>>>> >><br>
>>>>> >> This looks too complicated for me from the backend side, and option<br>
>>>>> >> with enabling/disabling plugins in wizard for specific environment<br>
>>>>> >> (we<br>
>>>>> >> can invent mechanism to disable them on env which is not deployed<br>
>>>>> >> yet,<br>
>>>>> >> besides, for API it's just one PUT) is MUCH simpler and much more<br>
>>>>> >> obvious, as I see.<br>
>>>>> >><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh<br>
>>>>> >> <<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>> wrote:<br>
>>>>> >> > Hi,<br>
>>>>> >> ><br>
>>>>> >> > I would go with the 1st approach. The thing I don't like in the<br>
>>>>> >> > 2nd<br>
>>>>> >> > approach<br>
>>>>> >> > is that we have to make the user enable plugin twice. For example,<br>
>>>>> >> > we<br>
>>>>> >> > have<br>
>>>>> >> > to enable Ceph as a plugin and then add Ceph role to nodes and<br>
>>>>> >> > choose<br>
>>>>> >> > what<br>
>>>>> >> > we want to store in Ceph (images, objects). Why we would need to<br>
>>>>> >> > explicitly<br>
>>>>> >> > enable Ceph plugin? Let's always show plugin options in wizard and<br>
>>>>> >> > settings<br>
>>>>> >> > tab, and if the user just doesn't want to enable Ceph, he would<br>
>>>>> >> > just<br>
>>>>> >> > leave<br>
>>>>> >> > all the checkboxes unchecked. The 2nd approach would also lead to<br>
>>>>> >> > some<br>
>>>>> >> > kind<br>
>>>>> >> > of inconsistency in case the user enabled Ceph plugin but left all<br>
>>>>> >> > the<br>
>>>>> >> > Ceph-related checkboxes unchecked and didn't add Ceph nodes.<br>
>>>>> >> ><br>
>>>>> >> > 2014-10-07 21:17 GMT+07:00 Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>>:<br>
>>>>> >> >><br>
>>>>> >> >> Hi,<br>
>>>>> >> >><br>
>>>>> >> >> We had a meeting today about plugins on UI, as result of the<br>
>>>>> >> >> meeting<br>
>>>>> >> >> we have two approaches and this approaches affect not only UX but<br>
>>>>> >> >> plugins itself.<br>
>>>>> >> >><br>
>>>>> >> >> 1st - disable/enable plugin on settings tab<br>
>>>>> >> >><br>
>>>>> >> >> user installs the plugin<br>
>>>>> >> >> creates a cluster<br>
>>>>> >> >> configures and enables/disables plugins on settings tab<br>
>>>>> >> >><br>
>>>>> >> >> For user it will look like Ceph plugin checkboxes on settings<br>
>>>>> >> >> tab,<br>
>>>>> >> >> if he enables checkbox, then we pass the parameter to<br>
>>>>> >> >> orchestrator<br>
>>>>> >> >> as `true`.<br>
>>>>> >> >><br>
>>>>> >> >> Cons:<br>
>>>>> >> >><br>
>>>>> >> >> plugin developer should define a checkbox in each plugin (for<br>
>>>>> >> >> plugin<br>
>>>>> >> >> disabling/enabling)<br>
>>>>> >> >> on the backend we have to enable all of the plugins for<br>
>>>>> >> >> environment,<br>
>>>>> >> >> because user can define any name for his checkbox and we won't be<br>
>>>>> >> >> able<br>
>>>>> >> >> to<br>
>>>>> >> >> find it and make appropriate mapping plugin <-> env<br>
>>>>> >> >> since all of the plugins are always "enabled" we have to run<br>
>>>>> >> >> tasks for<br>
>>>>> >> >> all<br>
>>>>> >> >> of the plugins, and each plugin should parse astute.yaml in order<br>
>>>>> >> >> to<br>
>>>>> >> >> figure<br>
>>>>> >> >> out if it's required to run task current script<br>
>>>>> >> >><br>
>>>>> >> >> Pros:<br>
>>>>> >> >><br>
>>>>> >> >> it won't require additional setting or step for wizard<br>
>>>>> >> >> user will be able to disable plugin after environment creation<br>
>>>>> >> >><br>
>>>>> >> >> 2nd - enable plugins in wizard<br>
>>>>> >> >><br>
>>>>> >> >> user installs the plugin<br>
>>>>> >> >> now he can choose specific plugins for his environment in wizard<br>
>>>>> >> >> after cluster is created, he can configure additional parameters<br>
>>>>> >> >> on<br>
>>>>> >> >> settings tab, if plugin provides any<br>
>>>>> >> >><br>
>>>>> >> >> Cons:<br>
>>>>> >> >><br>
>>>>> >> >> user won't be able to disable plugin after cluster is created<br>
>>>>> >> >> additional step or configuration subcategory in wizard<br>
>>>>> >> >><br>
>>>>> >> >> Pros:<br>
>>>>> >> >><br>
>>>>> >> >> On backend we always know which plugin is disabled and which is<br>
>>>>> >> >> enabled.<br>
>>>>> >> >><br>
>>>>> >> >> it means we don't provide settings for plugins which are disabled<br>
>>>>> >> >> we don't run tasks on slaves if it's not required<br>
>>>>> >> >><br>
>>>>> >> >> Thanks,<br>
>>>>> >> >><br>
>>>>> >> >> _______________________________________________<br>
>>>>> >> >> OpenStack-dev mailing list<br>
>>>>> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>> >> >><br>
>>>>> >> ><br>
>>>>> >> ><br>
>>>>> >> ><br>
>>>>> >> > --<br>
>>>>> >> > Vitaly Kramskikh,<br>
>>>>> >> > Software Engineer,<br>
>>>>> >> > Mirantis, Inc.<br>
>>>>> >> ><br>
>>>>> >> > _______________________________________________<br>
>>>>> >> > OpenStack-dev mailing list<br>
>>>>> >> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>> >> ><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> --<br>
>>>>> >> Best regards,<br>
>>>>> >> Nick Markov<br>
>>>>> >><br>
>>>>> >> _______________________________________________<br>
>>>>> >> OpenStack-dev mailing list<br>
>>>>> >> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>> ><br>
>>>>> ><br>
>>>>> ><br>
>>>>> > _______________________________________________<br>
>>>>> > OpenStack-dev mailing list<br>
>>>>> > <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>> ><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Best regards,<br>
>>>>> Nick Markov<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list<br>
>>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Vitaly Kramskikh,<br>
>>>> Software Engineer,<br>
>>>> Mirantis, Inc.<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> OpenStack-dev mailing list<br>
>>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Vitaly Kramskikh,<br>
>> Software Engineer,<br>
>> Mirantis, Inc.<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
</div></div><span><font color="#888888">Dmitry Borodaenko<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Dmitry Borodaenko</div></div>
</div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>