<div dir="ltr"><div><div>If there is no checkboxes (read configuration) and plugin is installed - all deployment tasks will be applied <br></div><div>to every environment, but why do you think that there will be no checkboxes in most cases?</div><div><br></div><div>Right now we already have like 2 types of plugins (extensions), classified by usage of settings tab:</div><div>1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or hypervisor (lvm/qemu/vmware)</div><div>2. Self-contained service that just needs to be installed (sahara, murano, zabbix)</div><div><br></div><div>In 1st case you need to provide shared configuration storage (like cluster attributes right now), in order for plugin</div></div><div>to be able to exclude part of core workflow from running (not installing swift for example). </div><div>In case if the plugin is self-contained entity, like Sahara, Murano right now - checkboxes would be simply required.</div><div>It works this way right now, and it doesnot look like huge overhead.</div><div><br></div><div>So what do you think, will it work or no?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov <span dir="ltr"><<a href="mailto:nmarkov@mirantis.com" target="_blank">nmarkov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<div><div class="h5"><br>
<br>
<br>
On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh<br>
<<a href="mailto:vkramskikh@mirantis.com">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 approach<br>
> is that we have to make the user enable plugin twice. For example, we have<br>
> to enable Ceph as a plugin and then add Ceph role to nodes and choose what<br>
> we want to store in Ceph (images, objects). Why we would need to explicitly<br>
> enable Ceph plugin? Let's always show plugin options in wizard and settings<br>
> tab, and if the user just doesn't want to enable Ceph, he would just leave<br>
> all the checkboxes unchecked. The 2nd approach would also lead to some 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">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 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 all<br>
>> of the plugins, and each plugin should parse astute.yaml in order to 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 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">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">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>Best regards,<br>
Nick Markov<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>