<p dir="ltr">Vitaly,</p>
<p dir="ltr">It's there a document or spec or a wiki page that describes the current status of this discussion in the context of the whole pluggable architecture design?</p>
<p dir="ltr">Jumping into this thread without having the whole picture is hard. Knowing what is already agreed, what is implemented so far, and having a structured summary of points of disagreement with pro and contra arguments would help a lot.</p>
<div class="gmail_quote">On Nov 28, 2014 9:48 AM, "Vitaly Kramskikh" <<a href="mailto:vkramskikh@mirantis.com">vkramskikh@mirantis.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Folks,<br><br></div>Please participate in this discussion. We already have a few meetings on this topic and there is still no decision. I understand entry level is pretty high, but please find some time for this.<br><br></div>Evgeniy,<br><br></div>Responses inline:<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-28 20:03 GMT+03: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"><span>>> <span style="font-family:arial,sans-serif;font-size:13px">Yes, but is already used in a few places. I want to notice once again - even a simple LBaaS plugin with a single checkbox needed to utilize this functionality.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></span><div><span style="font-family:arial,sans-serif;font-size:13px">Yes, but you don't need to specify it in each task.</span></div></div></blockquote><div>Just by adding conditions to tasks we will be able to pluginize all current functionality that can be pluginized. On the other hand, 1 line will be added to task definition and you are concerned about this that much that you want to create a separate interface for "complex" plugins. Am I right?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">>> </span><span style="font-family:arial,sans-serif;font-size:13px">So, you're still calling this interface complicated. Ok, I'm looking forward to seeing your proposal about dealing with complex plugins.</span><span style="font-family:arial,sans-serif;font-size:13px"> </span></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></span><div style="font-family:arial,sans-serif;font-size:13px">All my concerns were related to simple plugins and that we should</div><div style="font-family:arial,sans-serif;font-size:13px">find a way not to force a plugin developer to do this copy-paste work.</div></div></blockquote><div>I don't understand what copy-paste work you are talking about. Copying conditions from tasks to is_removable? Yes, it will be so in most cases, but not always, so we need to give a plugin writer a way to define is_removable manually. If you are talking about copypasting conditions between tasks (though I don't understand why we need a few tasks with the same conditions), YAML links can be used - we use them a lot in openstack.yaml.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">>> If you have several checkboxes, then it is a complex plugin with complex configuration ...</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Here we need a definition of s simple plugins, in the current</div><div style="font-family:arial,sans-serif;font-size:13px">release with simple plugins you can define some fields on the UI (not a</div><div style="font-family:arial,sans-serif;font-size:13px">single checkbox) and run several tasks if plugin is enabled.</div></div></blockquote><div>Ok, we can define simple plugin as a plugin which doesn't require modification of generated YAML files at all. But with proposed approach there is no need to somehow separate "simple" and "complex" plugins.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Thanks,</div><span style="font-family:arial,sans-serif;font-size:13px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"></div></blockquote></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 28, 2014 at 7:01 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>Evgeniy,<br><br></div>Responses inline:<br><div class="gmail_extra"><br><div class="gmail_quote"><span>2014-11-28 18:31 GMT+03: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 Vitaly,<div><br></div><div>I agree with you that conditions can be useful in case of complicated plugins, but</div><div>at the same time in case of simple cases it adds a huge amount of complexity.</div><div>I would like to avoid forcing user to know about any conditions if he wants</div><div>to add several text fields on the UI.</div><div><br></div><div>I have several reasons why we shouldn't do that:</div><div>1. conditions are described with yet another language with it's own syntax</div></div></blockquote></span><div>Yes, but is already used in a few places. I want to notice once again - even a simple LBaaS plugin with a single checkbox needed to utilize this functionality. <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2. the language is not documented (solvable)</div></div></blockquote></span><div>It is documented: <a href="http://docs.mirantis.com/fuel-dev/develop/nailgun/customization/settings.html#expression-syntax" target="_blank">http://docs.mirantis.com/fuel-dev/develop/nailgun/customization/settings.html#expression-syntax</a> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>3. complicated interface will lead to a lot of bugs for the end user, and it will be</div><div> a Fuel team's problem</div></div></blockquote></span><div>So, you're still calling this interface complicated. Ok, I'm looking forward to seeing your proposal about dealing with complex plugins. <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>4. in case of several checkboxes you'll have to write a huge conditions with</div><div> a lot of "and" statements and it'll be really easy to forget about some of them</div></div></blockquote></span><div>If you have several checkboxes, then it is a complex plugin with complex configuration, so I see no problem here. There will be many more places where you can "forget" stuff.<br></div><span><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>As result in simple cases plugin developer will have to specify the same</div><div>condition of every task in tasks.yaml file, add it to metadata.yaml.</div><div>If you add new checkbox, you should go through all of this files,</div><div>add "and lbaas:new_checkbox_name" statement.</div></div></blockquote></span><div>Once again, in simple cases checkbox and the conditions (one for task and one for is_removable) can be easily pregenerated by FPB, so plugin developer has to do nothing more. If you add a new checkbox which doesn't affect plugin removeability and tasks, you have to change nothing in plugin metadata.<br></div><div><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>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Nov 27, 2014 at 7:57 PM, Vitaly Kramskikh <span dir="ltr"><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div>Folks,<br><br></div>In the 6.0 release we'll support simple plugins for Fuel. The current architecture allows to create only very simple plugins and doesn't allow to "pluginize" complex features like Ceph, vCenter, etc. I'd like to propose some changes to make it possible. They are subtle enough and the plugin template still can be autogenerated by Fuel Plugin Builder. Here they are:<br><br><a href="https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf" target="_blank">https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf</a><br><div><div><ol><li><span title="lbaas/environment_config.yaml">environment_config.yaml should contain exact config which will be mixed into cluster_attributes. No need to implicitly generate any controls like it is done now.<br></span></li><li><span title="lbaas/metadata.yaml">metadata.yaml should also contain "is_removable" field. </span><span title="lbaas/metadata.yaml"><span title="lbaas/metadata.yaml">This field is needed to
determine whether it is possible to remove installed plugin. It is
impossible to remove plugins in the current implementation.</span> This field should contain an expression written in our DSL which we already use in a few places. The LBaaS plugin also uses it to hide the checkbox if Neutron is not used, so even simple plugins like this need to utilize it. This field can also be autogenerated, for more complex plugins plugin writer needs to fix it manually. For example, for Ceph it could look like "settings:storage.volumes_ceph.value == false and settings:storage.images_ceph.value == false".<br></span></li><li><span title="lbaas/metadata.yaml">For every task in </span><span title="lbaas/tasks.yaml">tasks.yaml there should be added new "condition" field with an expression which determines whether the task should be run. In the current implementation tasks are always run for specified roles. For example, vCenter plugin can have a few tasks with conditions like "settings:common.libvirt_type.value == 'vcenter'" or "settings:storage.volumes_vmdk.value == true". Also, AFAIU, similar approach will be used in implementation of Granular Deployment feature.<br></span></li></ol><p>These simple changes will allow to write much more complex plugins. What do you think?<span><font color="#888888"><br></font></span></p><span><font color="#888888">-- <br><div><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></div>
</font></span></div></div></div>
<br></div></div>_______________________________________________<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>
<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></div></div><div><div><br><br clear="all"><br>-- <br><div><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></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"><br>-- <br><div><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></div>
</div></div></div></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>