<p dir="ltr">Vitaly, </p>
<p dir="ltr">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:<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 enabled both on UI and CLI (and through pure API by simple field checking)</p>
<p dir="ltr">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.</p>
<p dir="ltr">How will it work with your approach?</p>
<div class="gmail_quote">08 Окт 2014 г. 20:00 пользователь "Vitaly Kramskikh" <<a href="mailto:vkramskikh@mirantis.com">vkramskikh@mirantis.com</a>> написал:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi, responses inline.<br><div class="gmail_extra"><br><div class="gmail_quote">2014-10-08 21:09 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 understand your concerns about UX.</div><div>But there are technical problems and statements which affect</div><div>plugin developer and makes his live more complicated.</div><div><br></div><div>My opinion is we definitely should know, if plugin is disabled</div><div>or if it's enabled for specific environment.</div><div><br></div><div>1. plugin developer defines tasks, like "I want the script to be</div><div> executed on nodes with controller role" and I don't think that</div><div> he expects this task to be run on all of the nodes, also</div><div> I don't think that we want ask plugin developer to parse</div><div> yaml with bash in order to understand if his plugin is enabled,</div><div> it's a bad design</div></div></blockquote><div>Bash script shouldn't be even run if the conditions to run it are not met. I described above how it could be done. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2. there will be no way to uninstall the plugin, because all of the</div><div> plugins are enabled on the environments, even if user doesn't</div><div> use them</div></div></blockquote><div>Well, this is the only issue that I see with the first approach and I still don't know how to solve it. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Also I don't think that it's a good interface, to ask plugin developr</div><div>to include checkbox in each plugin.</div><div><br></div></div></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>The second solution is discussed because it's the most explicit</div><div>way to solve described problem.</div><div><br></div><div>Let's try to figure out the solution which will work well for user</div><div>and for plugin developer.</div><div><br></div><div>For example, for each plugin generate section on UI with checkbox</div><div>Like:</div></div></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>GlusterFS [ ] - disable all of the fields for the section</div><div>Here is some description of the section, which we can take from</div><div>description field.</div><div><br></div><div>IP address [127.0.0.1] - this field provides plugin developer</div><div><br></div><div>If plugin is set, we add env <-> plugin relation, if it's unset, we</div><div>delete it.</div><div>Also when user checks the checkbox, UI will be able to retrieve</div><div>attributes which plugin provides. But it's not so easy todo, I'm not</div><div>sure if we can do it with hooks, but it's possible with some separate</div><div>model and handlers.</div><div><br></div><div>Thanks,</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 12:48 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>Nikolay,<br><br>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 <a href="http://en.wikipedia.org/wiki/Single_Source_of_Truth" target="_blank">SSOT</a>, and you want to ruin it for no reason.<br><br></div>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.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-08 14:50 GMT+07:00 Nikolay Markov <span dir="ltr"><<a href="mailto:nmarkov@mirantis.com" target="_blank">nmarkov@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>>>> Right now we already have like 2 types of plugins (extensions), classified by usage of settings tab:<br>
>>> 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or hypervisor (lvm/qemu/vmware)<br>
>>> 2. Self-contained service that just needs to be installed (sahara, murano, zabbix)<br>
<br>
</span>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>
<div><div><br>
On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak <<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@mirantis.com</a>> wrote:<br>
> If there is no checkboxes (read configuration) and plugin is installed - all<br>
> deployment tasks will be applied<br>
> to every environment, but why do you think that there will be no checkboxes<br>
> in most cases?<br>
><br>
> Right now we already have like 2 types of plugins (extensions), classified<br>
> by usage of settings tab:<br>
> 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or<br>
> hypervisor (lvm/qemu/vmware)<br>
> 2. Self-contained service that just needs to be installed (sahara, murano,<br>
> zabbix)<br>
><br>
> In 1st case you need to provide shared configuration storage (like cluster<br>
> attributes right now), in order for plugin<br>
> to be able to exclude part of core workflow from running (not installing<br>
> swift for example).<br>
> In case if the plugin is self-contained entity, like Sahara, Murano 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>> 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 be<br>
>> applied while generating astute.yaml and tasks.yaml? Should we<br>
>> autogenerate some stuff for plugins which are not even enabled and 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 (we<br>
>> can invent mechanism to disable them on env which is not deployed 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 2nd<br>
>> > approach<br>
>> > is that we have to make the user enable plugin twice. For example, we<br>
>> > have<br>
>> > to enable Ceph as a plugin and then add Ceph role to nodes and 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 just<br>
>> > leave<br>
>> > all the checkboxes unchecked. The 2nd approach would also lead to some<br>
>> > kind<br>
>> > of inconsistency in case the user enabled Ceph plugin but left all 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 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 tab,<br>
>> >> if he enables checkbox, then we pass the parameter to orchestrator<br>
>> >> as `true`.<br>
>> >><br>
>> >> Cons:<br>
>> >><br>
>> >> plugin developer should define a checkbox in each plugin (for plugin<br>
>> >> disabling/enabling)<br>
>> >> on the backend we have to enable all of the plugins for environment,<br>
>> >> because user can define any name for his checkbox and we won't be 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 tasks for<br>
>> >> all<br>
>> >> of the plugins, and each plugin should parse astute.yaml in order 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 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>
</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>
<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>