<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@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"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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><ul><li>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></li></ul></div></blockquote></span><div> Initially i had the same thoughts and wanted to use it the way it is, but now i completely agree with Evgeniy that additional DSL will cause a lot</div><div>of problems with compatibility between versions and developer experience.</div></div></div></div></blockquote><div>As far as I understand, you want to introduce another approach to describe UI part or 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 class="gmail_extra"><div class="gmail_quote"><div>We need to search for alternatives..</div><div>1. for UI i would prefer separate tab for plugins, where user will be able to enable/disable plugin explicitly.</div></div></div></div></blockquote><div>Of course, we need a separate page for plugin management. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Currently settings tab is overloaded.</div><div>2. on backend we need to validate plugins against certain env before enabling it,</div><div>   and for simple case we may expose some basic entities like network_mode.</div><div>For case where you need complex logic - python code is far more flexible that new DSL.</div><span class=""><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><ul><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".</span> </li></ul></div></blockquote></span><div>How checkbox will help? There is several cases of plugin removal..</div></div></div></div></blockquote><div>It is not a checkbox, this is condition that determines whether the plugin is removable. It allows plugin developer specify when plguin can be safely removed from Fuel if there are some environments which were created after the plugin had been installed.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>1. Plugin is installed, but not enabled for any env - just remove the plugin</div><div>2. Plugin is installed, enabled and cluster deployed - forget about it for now..</div><div>3. Plugin is installed and only enabled - we need to maintain state of db consistent after plugin is removed, it is problematic, but possible</div></div></div></div></blockquote><div>My approach also allows to eliminate "enableness" of plugins which will cause UX issues and issues like you described above. vCenter and Ceph also don't have "enabled" state. vCenter has hypervisor and storage, Ceph provides backends for Cinder and Glance which can be used simultaneously or only one of them can be used.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>My main point that plugin is enabled/disabled explicitly by user, after that we can decide ourselves can it be removed or not.</div><span class=""><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><ul><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.</span><br></li></ul></div></blockquote></span></div>I had some thoughts about using DSL, it seemed to me especially helpfull when you need to disable part of embedded into core functionality,</div><div class="gmail_extra">like deploying with another hypervisor, or network dirver (contrail for example). And DSL wont cover all cases here, this quite similar to metadata.yaml, simple cases can be covered by some variables in tasks (like group, unique, etc), but complex is easier to test and describe in python.</div></div></blockquote><div>Could you please provide example of such conditions? vCenter and Ceph can be turned into plugins using this approach.<br><br></div><div>Also, I'm not against python version of plugins. It could look like a python class with exactly the same fields form YAML files, but conditions will be written in python.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></div>
</div></div>