<div dir="ltr"><div>As I said, it is not flexible and restrictive. What if there are some other "backends" for anything appear? What to do if I want to write a plugin that just adds some extra styles to the UI? Invent a new structures/flags on demand? That's not viable.<br><br></div>I still think "enableness" of plugin is the root of all issues with your approach. With your approach we lose single source of truth (cluster attributes/settings tab) we'll need to search for strange solutions like these groups/flags.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-17 12:33 GMT+01:00 Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Vitaly, what do you think about that?</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:13px">Hi,</div><div style="font-size:13px"><br></div><div style="font-size:13px">I don't agree with many of your statements but, I would like to</div><div style="font-size:13px">continue discussion about really important topic i.e. UI flow, my</div><div style="font-size:13px">suggestion was to add groups, for plugin in metadata.yaml plugin</div><div style="font-size:13px">developer can have description of the groups which it belongs to:</div><div style="font-size:13px"><br></div><div style="font-size:13px">groups:</div><div style="font-size:13px"> - id: storage</div><div style="font-size:13px"> subgroup:</div><div style="font-size:13px"> - id: cinder</div><div style="font-size:13px"><br></div><div style="font-size:13px">With this information we can show a new option on UI (wizard),</div><div style="font-size:13px">if option is selected, it means that plugin is enabled, if plugin belongs</div><div style="font-size:13px">to several groups, we can use OR statement.</div><div style="font-size:13px"><br></div><div style="font-size:13px">The main point is, for environment creation we must specify</div><div style="font-size:13px">ids of plugins. Yet another reason for that is plugins multiversioning,</div><div style="font-size:13px">we must know exactly which plugin with which version</div><div style="font-size:13px">is used for environment, and I don't see how "conditions" can help</div><div style="font-size:13px">us with it.</div><div style="font-size:13px"><br></div><div style="font-size:13px">Thanks,</div><span style="font-size:13px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><ul></ul></div></div></div></blockquote></div></div></div></blockquote></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh <span dir="ltr"><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2014-12-10 19: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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Dec 10, 2014 at 6:50 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>2014-12-10 16:57 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>First let me describe what our plans for the nearest release. We want to deliver</div><div>role as a simple plugin, it means that plugin developer can define his own role</div><div>with yaml and also it should work fine with our current approach when user can</div><div>define several fields on the settings tab.</div><div><br></div><div>Also I would like to mention another thing which we should probably discuss</div><div>in separate thread, how plugins should be implemented. We have two types<br></div><div>of plugins, simple and complicated, the definition of simple - I can do everything</div><div>I need with yaml, the definition of complicated - probably I have to write some</div><div>python code. It doesn't mean that this python code should do absolutely</div><div>everything it wants, but it means we should implement stable, documented</div><div>interface where plugin is connected to the core.</div><div><br></div><div>Now lets talk about UI flow, our current problem is how to get the information</div><div>if plugins is used in the environment or not, this information is required for</div><div>backend which generates appropriate tasks for task executor, also this</div><div>information can be used in the future if we decide to implement plugins deletion</div><div>mechanism.</div><div><br></div><div>I didn't come up with a some new solution, as before we have two options to</div><div>solve the problem:</div><div><br></div><div># 1</div><div><br></div><div>Use conditional language which is currently used on UI, it will look like</div><div>Vitaly described in the example [1].</div><div>Plugin developer should:</div><div><br></div><div>1. describe at least one element for UI, which he will be able to use in task</div><div><br></div><div>2. add condition which is written in our own programming language</div><div><br></div><div>Example of the condition for LBaaS plugin:</div><div><br></div><div> condition: settings:lbaas.metadata.enabled == true<br></div><div><br></div><div>3. add condition to metadata.yaml a condition which defines if plugin is enabled</div><div><br></div><div> is_enabled: settings:lbaas.metadata.enabled == true<br></div><div><br></div><div>This approach has good flexibility, but also it has problems:</div><div><br></div><div>a. It's complicated and not intuitive for plugin developer.</div></div></blockquote></div></div><div>It is less complicated than python code <br></div></div></div></div></blockquote><div><br></div></div></div><div>I'm not sure why are you talking about python code here, my point</div><div>is we should not force developer to use this conditions in any language.</div><div><br></div></div></div></div></blockquote></div></div><div>But that's how current plugin-like stuff works. There are various tasks which are run only if some checkboxes are set, so stuff like Ceph and vCenter will need conditions to describe tasks.<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Anyway I don't agree with the statement there are more people who know</div><div>python than "fuel ui conditional language".<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>b. It doesn't cover case when the user installs 3rd party plugin<br></div><div> which doesn't have any conditions (because of # a) and</div><div> user doesn't have a way to disable it for environment if it</div><div> breaks his configuration.</div></div></blockquote></span><div>If plugin doesn't have conditions for tasks, then it has invalid metadata.<br></div></div></div></div></blockquote><div><br></div></span><div>Yep, and it's a problem of the platform, which provides a bad interface.</div></div></div></div></blockquote></span><div>Why is it bad? It plugin writer doesn't provide plugin name or version, then metadata is invalid also. It is plugin writer's fault that he didn't write metadata properly. <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div># 2</div><div><br></div><div>As we discussed from the very beginning after user selects a release he can</div><div>choose a set of plugins which he wants to be enabled for environment.</div><div>After that we can say that plugin is enabled for the environment and we send</div><div>tasks related to this plugin to task executor.</div><span><div><br></div><div>>> <span style="font-size:13px">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.</span></div><div><span style="font-size:13px"><br></span></div></span><div><span style="font-size:13px">Both of described plugins have enabled/disabled state, vCenter is enabled</span></div><div><span style="font-size:13px">when vCenter is selected as hypervisor. Ceph is enabled when it's selected</span></div><div><span style="font-size:13px">as a backend for Cinder or Glance.</span></div></div></blockquote></span><div>Nope, Ceph for Volumes can be used without Ceph for Images. Both of these plugins can also have some granular tasks which are enabled by various checkboxes (like VMware vCenter for volumes). How would you determine whether tasks which installs VMware vCenter for volumes should run?<br></div></div></div></div></blockquote><div><br></div></span><div>Why "nope"? I have "<span style="font-size:13px">Cinder OR Glance".</span> <br></div></div></div></div></blockquote></span><div>Oh, I missed it. So there are 2 checkboxes, how would you determine "enableness"? <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It can be easily handled in deployment script.<br></div></div></div></div></blockquote></span><div>I don't know much about the status of granular deployment blueprint, but AFAIK that's what we are going to get rid of.<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><span style="font-size:13px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:13px"><br></span></div><div>If you don't like the idea of having Ceph/vCenter checkboxes on the first page,</div><div>I can suggest as an idea (research is required) to define groups like Storage Backend,</div><div>Network Manager and we will allow plugin developer to embed his option in radiobutton</div><div>field on wizard pages. But plugin developer should not describe conditions, he should</div><div>just write that his plugin is a Storage Backend, Hypervisor or new Network Manager.</div><div>And the plugins e.g. Zabbix, Nagios, which don't belong to any of this groups</div><div>should be shown as checkboxes on the first page of the wizard.</div></div></blockquote></span><div>Why don't you just ditch "enableness" of plugins and get rid of this complex stuff? Can you explain why do you need to know if plugin is "enabled"? Let me summarize my opinion on this:</div></div></div></div></blockquote><div> </div></span><div>I described why we need it many times. Also it looks like you skipped another option</div><div>and I would like to see some more information why you don't like it and why it's</div><div>a bad from UX stand point of view.</div></div></div></div></blockquote></span><div>Yes, I skipped it. You said "research is required", so please do it, write a proposal and then we will compare it with condition approach. You still don't have your proposal, so there is nothing to compare and discuss. From the first perspective it seems complex and restrictive.<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><ul><li>You don't need to know whether plugin is enabled or not. You need to know what tasks should be run and whether plugin is removable (anything else?). These conditions can be described by the DSL.<br></li></ul></div></div></div></div></blockquote></span><div>I do need to know if plugin is enabled to figure out if it's removable, in fact those are the same things.</div></div></div></div></blockquote></span><div>So there is nothing else you need "enableness", right? If you "described why we need it many times", I think you need to do it one more time (in form of a list). If we need "enableness" just to determine whether the plugin is removable, then it is not the reason to ruin our UX.<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><ul><li></li><li>Explicitly asking the user to enable plugin for new environment should be considered as a last resort solution because it significantly impair our UX for inexperienced user. Just imagine: a new user which barely knows about OpenStack chooses a name for the environment, OS release and then he needs to choose plugins. Really?</li></ul></div></div></div></div></blockquote></span><div>I really think that it's absolutely ok to show checkbox with LBaaS for the user who found the</div><div>plugin, downloaded it on the master and installed it with CLI.</div><div><br></div><div>And right now this user have to go to this settings tab with attempts to find this checkbox,</div><div>also he may not find it for example because of incompatible release version, and it's clearly</div><div>a bad UX.</div></div></div></div></blockquote></span><div>I like how it is done in modern browsers - after upgrade of master node there is notification about incompatible plugins, and in list of plugins there is a message that plugin is incompatible. We need to design how we will handle it. Currently it is definitely a bad UX because nothing is done for this.<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><p>My proposal for "complex" plugin interface: there should be python classes with exactly the same fields from yaml files: plugin name, version, etc. But condition for cluster deletion and for tasks which are written in DSL in case of "simple" yaml config should become methods which plugin writer can make as complex as he wants.</p></div></div></div></div></blockquote></span><div>Why do you want to use python to define plugin name, version etc? It's a static data which are</div><div>used for installation, I don't think that in fuel client (or some other installation tool) we want</div><div>to unpack the plugin and import this module to get the information which is required for installation.<br></div></div></div></div></blockquote></span><div>It is just a proposal in which I try to solve problems which you see in my approach. If you want a "complex" interface with arbitrary python code, that's how I see it. All fields are the same here, the approach is the same, just conditions are in python. And YAML config can be converted to this class, and all other code won't need to handle 2 different interfaces for plugins.<br></div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><p></p></div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-size:13px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div></blockquote></span><div><br></div><div>[1] <a href="https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf" target="_blank">https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf</a></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 30, 2014 at 3:12 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>As far as I understand, you want to introduce another approach to describe UI part or plugins?<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>Of course, we need a separate page for plugin management. <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></span></div><br><br clear="all"><span><br>-- <br><div><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></div>
</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>
<br></blockquote></div><br></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 30, 2014 at 3:12 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>As far as I understand, you want to introduce another approach to describe UI part or plugins?<br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><div>Of course, we need a separate page for plugin management. <br></div><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></span></div><br><br clear="all"><span><br>-- <br><div><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></div>
</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>
<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></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></div></div><br></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></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></div>
</div></div></blockquote></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><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Vitaly Kramskikh,<br>Software Engineer,<br>Mirantis, Inc.</div></div>
</div>