<div dir="ltr"><div>Hi,<br><br></div>As for a separate section for plugins, I think we should not force it and leave this decision to a plugin developer, so he can create just a single checkbox or a section of the settings tab or a separate tab depending on plugin functionality. Plugins should be able to modify arbitrary release fields. For example, if Ceph was a plugin, it should be able to extend wizard config to add new options to Storage pane. If vCenter was a plugin, it should be able to set maximum amount of Compute nodes to 0.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-20 21:21 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 guys,<div><br></div><div><b>Romans' questions:</b></div><span class=""><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">>> I feel like we should not require user to unpack the plugin before installing it.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">>> Moreover, we may chose to distribute plugins in our own format, which we</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">>> may potentially change later. E.g. "lbaas-v2.0.fp".</span><br></div><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">I like the idea of putting plugin installation functionality in fuel client, which is installed</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">on master node.</span></div><div><font face="arial, sans-serif">But in the current version plugin installation requires files operations on the master,</font></div><div><font face="arial, sans-serif">as result we can have problems if user's fuel-client is installed on another env.</font></div><div><font face="arial, sans-serif">What we can do is to try to determine where fuel-client is installed, if it's master</font></div><div><font face="arial, sans-serif">node, we can perform installation, if it isn't master node, we can show user the</font></div><div><font face="arial, sans-serif">message, that in the current version remote plugin installation is not supported.</font></div><div><font face="arial, sans-serif">In the next versions if we implement plugin manager (which is separate service</font></div><div><font face="arial, sans-serif">for plugins management) we will be able to do it remotely.</font></div><div><span class=""><div><br></div><div>>> <span style="font-family:arial,sans-serif;font-size:13px">How are we planning to distribute fuel plugin builder and its updates?</span><span style="font-family:arial,sans-serif;font-size:13px"> </span></div><div><br></div></span><div><font face="arial, sans-serif">Yes, as Mike mentioned our plan is to release it on PyPi which is python packages</font></div><div><font face="arial, sans-serif">repository, so any developer will be able to run `pip install fpb` and get the tool.</font></div><span class=""><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">>> </font><span style="font-family:arial,sans-serif;font-size:13px">What happens if an error occurs during plugin installation?</span></div><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">Plugins installation process is very simple, our plan is to have some kind of transaction,</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">to make it atomic.</span></div><div><br></div><div>1. register plugin via API</div><div>2. copy the files</div><div><br></div><div>In case of error on the 1st step, we can do nothing, in case of error on the 2nd step,</div><div>remove files if there are any, and delete a plugin via rest api. And show user a message.</div><span class=""><div><br></div><div>>> <span style="font-family:arial,sans-serif;font-size:13px">What happens if an error occurs during plugin execution?</span></div><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">In the first iteration we are going to interrupt deployment if there are any errors for plugin's</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">tasks, also we are thinking how to improve it, for example we wanted to provide a special</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">flag for each task, like fail_deploument_on_error, and only if it's true, we fail </span><span style="font-size:13px;font-family:arial,sans-serif">deployment </span><span style="font-size:13px;font-family:arial,sans-serif">in</span></div><div><span style="font-size:13px;font-family:arial,sans-serif">case of failed task. But it can be </span><font face="arial, sans-serif">tricky to implement, it requires to change the </font><font face="arial, sans-serif">current</font></div><div><font face="arial, sans-serif">orchestrator/</font><span style="font-family:arial,sans-serif">nailgun error handling logic. So, I'm not sure if we can implement </span><span style="font-family:arial,sans-serif">this logic in</span></div><div><span style="font-family:arial,sans-serif">the first release.</span></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Regarding to meaningful error messages, yes, we want to show the user, which plugin</font></div><div><font face="arial, sans-serif">causes </font><span style="font-family:arial,sans-serif">the error.</span></div><span class=""><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">>> </font><span style="font-family:arial,sans-serif;font-size:13px">Shall we consider a separate place in UI (tab) for plugins?</span></div><div><span style="font-family:arial,sans-serif"><br></span></div></span><div><span style="font-family:arial,sans-serif">+1 to Mike's answer </span></div><span class=""><div><span style="font-family:arial,sans-serif"><br></span></div><div><span style="font-family:arial,sans-serif">>> </span><span style="font-family:arial,sans-serif;font-size:13px">When are we planning to focus on the 2 plugins which were identified as must-haves</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">>> for 6.0? Cinder & LBaaS</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></span><div><font face="arial, sans-serif">For Cinder we are going to implement plugin which configures GlusterFS as cinder backend,</font></div><div><font face="arial, sans-serif">so, if user has installed GlusterFS cluster, we can configure our cinder to work with it,</font></div><div><font face="arial, sans-serif">I want to mention that we don't install GlusterFS nodes, we just configure cinder to work</font></div><div><font face="arial, sans-serif">with user's </font><span style="font-family:arial,sans-serif">GlusterFS </span><span style="font-family:arial,sans-serif">cluster.</span></div><div>Stanislaw B. already did some scripts which configures cinder to work with GlusterFS, so</div><div>we are on testing stage.</div><div><br></div><div>Regarding to LBaaS, Stanislaw B. did multinode implementation, ha implementation is tricky</div><div>and requires some additional work, we are working on it.</div><div><br></div><div><b class="gmail_sendername" style="font-family:arial,sans-serif;font-size:13px">Nathan's questions:</b><br></div><div><b class="gmail_sendername" style="font-family:arial,sans-serif;font-size:13px"><br></b></div><div>Looks like Mike answered UI related questions.</div><span class=""><div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">>> Do we offer any kind of validation for settings on plug-ins?   Or some way to for the developer</div><div style="font-family:arial,sans-serif;font-size:13px">>> to ensure that setting that cannot be default or computed get requested for the plug-in?</div></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></span><div style="font-family:arial,sans-serif;font-size:13px">Yes, each field can have regexp which is used during the validation.</div><div><br></div><div><b>Mike's questions:</b></div><span class=""><div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">>> One minor thing from me, which I forgot to mention during the demo: verbosity of fpb run. I</div><div style="font-family:arial,sans-serif;font-size:13px">>> understand it might sound like a bikeshedding now, but I believe if we develop it right from</div><div style="font-family:arial,sans-serif;font-size:13px">>> the very beginning, then we can save some time later. So I would suggest normal, short INFO</div><div style="font-family:arial,sans-serif;font-size:13px">>> output, and verbose one with --debug.</div></div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></span><div style="font-family:arial,sans-serif;font-size:13px">Agree.</div><div><br></div><div>Thanks for your feedback,</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Oct 19, 2014 at 1:11 PM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@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 class="h5"><div dir="ltr"><div>Hi all,</div><div>I moved this conversation to openstack-dev to get a broader audience, since we started to discuss technical details.</div><div><br></div><div>Raw notes from demo session: <a href="https://etherpad.openstack.org/p/cinder-neutron-plugins-second-demo" target="_blank">https://etherpad.openstack.org/p/cinder-neutron-plugins-second-demo</a>.</div><div><br></div><div>Let me start answering on a few questions below from Roman & Nathan.</div><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"><span style="color:rgb(80,0,80)">How are we planning to distribute fuel plugin builder and its updates? Ideally, it should be available externally (outside of master node). I don't want us to repeat the same mistake as we did with Fuel client, which doesn't seem to be usable as an external dependency.</span></blockquote><div>The plan was to have Fuel Plugin Builder (fpb) on PyPI. Ideally it should be backward compatible with older Fuel release, i.e. when there is Fuel 7.0 out, you should be still able to create plugin for Fuel 6.0. If that it is going to be overcomplicated - I suggested to produce fpb for every Fuel release, and name it like fpb60, fpb61, fpb70, etc. Then it becomes easier to support and maintain plugin builders for certain versions of Fuel.</div><div>Speaking about Fuel Client - there is no mistake. It's been discussed dozens of times, it's just lack of resources to make it on PyPI as well as to fix a few other things. I hope it could be done as part of efforts from [2].</div><div><br></div><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">- Perhaps we have a separate settings tab just for Plug-Ins?    For some complex plug-ins, they might require a dedicated tab.   If we have too many tabs it could get messy.</blockquote><div> </div><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"><span style="color:rgb(80,0,80)">Shall we consider a separate place in UI (tab) for plugins? Settings tab seems to be overloaded.</span></blockquote><div> </div><div>This is certainly under planning and discussion for future releases. See [1], for example. For 6.0, we agreed that we can just extend existing Settings tab with plugins-related fields.</div><div><br></div><div>One minor thing from me, which I forgot to mention during the demo: verbosity of fpb run. I understand it might sound like a bikeshedding now, but I believe if we develop it right from the very beginning, then we can save some time later. So I would suggest normal, short INFO output, and verbose one with --debug.</div><div><br></div><div>Thanks for feedback folks!!!</div><div><br></div><div>[1] <a href="https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37196.html" target="_blank">https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37196.html</a></div><div>[2] <a href="https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37001.html" target="_blank">https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37001.html</a></div><div><br></div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Nathan Trueblood</b> <span dir="ltr"><<a href="mailto:ntrueblood@mirantis.com" target="_blank">ntrueblood@mirantis.com</a>></span><br>Date: Sat, Oct 18, 2014 at 3:24 AM<br>Subject: Re: plugins<br><br><div dir="ltr">Agreed - I thought this initial PoC was great.<div><br></div><div>A few initial thoughts about settings in the UI and plug-in in general:</div><div><br></div><div>- Perhaps we have a separate settings tab just for Plug-Ins?    For some complex plug-ins, they might require a dedicated tab.   If we have too many tabs it could get messy.</div><div>- It seems like we should consider how we handle the VMWare settings in light of plug-ins as well.   Since with VMWare we have a lot of setting to configure and settings validation.</div><div>- Do we offer any kind of validation for settings on plug-ins?   Or some way to for the developer to ensure that setting that cannot be default or computed get requested for the plug-in?</div><div><br></div><div>- We need to think carefully about both the plug-in developer experience (how hard to test, get error messages, etc) and the experience for the user who deploys the plug-in into an environment.</div><span><font color="#888888"><div><br></div><div><br></div><div>-Nathan</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 4:13 PM, Roman Alekseenkov <span dir="ltr"><<a href="mailto:ralekseenkov@mirantis.com" target="_blank">ralekseenkov@mirantis.com</a>></span> wrote:<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><br></div>I watched both videos (creating a file with the text from UI && installing and starting a service).<div><br><div><div>It looks pretty good!! Some initial feedback/questions:</div><div><ol><li>I like the fact that fuel plugin builder appends version to the name and makes it "fuel-awesome-plugin-1.2.3.tar". The approach is similar to Java/Maven and is a good one.</li><li>I feel like we should not require user to unpack the plugin before installing it. Moreover, we may chose to distribute plugins in our own format, which we may potentially change later. E.g. "lbaas-v2.0.fp". I'd rather stick with two actions:</li><ul><li>Assembly (externally): fpb --build <name></li><li>Installation (on master node): fuel --install-plugin <name></li></ul><li>How are we planning to distribute fuel plugin builder and its updates? Ideally, it should be available externally (outside of master node). I don't want us to repeat the same mistake as we did with Fuel client, which doesn't seem to be usable as an external dependency.</li><li>How do we handle errors?</li><ul><li>What happens if an error occurs during plugin installation?<br></li><li>What happens if an error occurs during plugin execution? Does it (should it?) fail the deployment? Will we show user an error message with the name of plugin that failed?<br></li></ul><li>Shall we consider a separate place in UI (tab) for plugins? Settings tab seems to be overloaded.</li><li>When are we planning to focus on the 2 plugins which were identified as must-haves for 6.0? Cinder & LBaaS</li></ol><div>Once again, great job guys!</div></div><div><br></div><div>Thanks,</div></div><div>Roman</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 9:32 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br><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"><p dir="ltr">Thanks, Evgeny, excellent work!<br>
Roman, I believe we are "green" with the feature. Watch yourself.</p>
<p dir="ltr">Mike Scherbakov<br>
#mihgen</p>
<div class="gmail_quote">On Oct 17, 2014 8:25 PM, "Evgeniy L" <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>> wrote:<br type="attribution"><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">Hi guys, here are the videos from the demo<div><br></div><div>Part 1</div><div><a href="https://drive.google.com/file/d/0B7I3b5vI7ZYXUGY1QVYyX3NLTWc/view" target="_blank">https://drive.google.com/file/d/0B7I3b5vI7ZYXUGY1QVYyX3NLTWc/view</a><br></div><div><br></div><div>Part 2</div><div><a href="https://drive.google.com/file/d/0B7I3b5vI7ZYXWkRmV05fT1VEQkk/view" target="_blank">https://drive.google.com/file/d/0B7I3b5vI7ZYXWkRmV05fT1VEQkk/view</a><br></div><div><br></div><div>Thanks,</div><div><br></div></div>
</blockquote></div>
</blockquote></div><br></div></div><span><font color="#888888">
</font></span></blockquote></div></div></div></div></div><span><font color="#888888"><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</font></span></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">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>