<div dir="ltr">Regarding #2<div></div><div dir="ltr"><div>> we already generate from templates required information for a plugin developer to start development</div></div><div dir="ltr"><div><div>and it is great.</div></div></div><div dir="ltr"><div>So, back to what I said:</div><div>> <span style="line-height:1.5">However, we can have fpb generating template plugin, with commented code in there. If you uncomment, you a get a comprehensive example of a working plugin. </span><span style="line-height:1.5">To ensure that uncommented code would actually work, we must have a test for it (which would uncomment - run - ensure everything deploys).</span></div></div><div dir="ltr"><div><span style="line-height:1.5">We already have great template plugins generated by fpb. Question is, how do we ensure that this generated template actually works.</span></div></div><div dir="ltr"><div><span style="line-height:1.5"><br></span></div><div>> <span style="line-height:1.5"># 3 adding real deployment test for fuel-plugins will not help here, since change in openstack.yaml caused this problem.</span></div></div><div dir="ltr"><div><span style="line-height:1.5">True. That's why I started new thread, where I suggest that we must allow to install older plugins into new releases of Fuel, with the warning only.</span></div></div><div><br></div><div>> Well, what about tomorrow? On SCF we create stable branches and master is open for next release. You probably will want to run those tests</div>against Fuel 10, and FPB's master won't have that "10" release in<br>examples metadata. <div>True Igor, please see my same answer to Evgeny above - we need to change pluggable framework to allow installation of older plugins to newer releases of Fuel. Before we do that, I suggest to extend supported releases list right away to Newton. No need to wait for new bug from QA.</div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 10, 2016 at 5:44 AM Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, what about tomorrow? On SCF we create stable branches and master<br>
is open for next release. You probably will want to run those tests<br>
against Fuel 10, and FPB's master won't have that "10" release in<br>
examples metadata. Because it's something that we usually don't want<br>
to release, and FPB lifecycle is untied from Fuel's.<br>
<br>
The only way to avoid that problem is to teach tests to prepare<br>
plugins themselves. They are like test fixtures, it's not very good<br>
that your rely on something that you don't maintain.<br>
<br>
On Thu, Mar 10, 2016 at 11:01 AM, Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>> wrote:<br>
> Mike,<br>
><br>
> # 2 don't agree, we already generate from templates required information for<br>
> a plugin developer to start development, purpose of plugin examples is<br>
> different, it's used as integration tests for plugins, also QA team uses<br>
> them as Functional tests, they overloaded with tasks and designed to have<br>
> good coverage, so it will only confuse plugin developer.<br>
> # 3 adding real deployment test for fuel-plugins will not help here, since<br>
> change in openstack.yaml caused this problem.<br>
><br>
> Thanks,<br>
><br>
> On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn <<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> Mike,<br>
>><br>
>> #1 - If you truly agree with that, you should weigh in here:<br>
>> <a href="https://review.openstack.org/#/c/287286/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/287286/</a><br>
>> #2 - Requires a blueprint and new docs, but okay.<br>
>> #3 - Yes! We have very poor CI for fuel plugin builder. All it does is<br>
>> ensure it makes a plugin, not that it can be installed and deployed.<br>
>><br>
>> On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov<br>
>> <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>> wrote:<br>
>> > Folks,<br>
>> > here is what I think:<br>
>> > 1) I suggest to fix what is broken now. So that people who come across<br>
>> > examples would not have to deal with issues. We may debate for other few<br>
>> > days (hopefully not more), and all plugin devs will be suffering during<br>
>> > this<br>
>> > time. Also, according to Matt,<br>
>> ><br>
>> >> I should add that this is the only automated daily test that will<br>
>> >> verify<br>
>> > that our plugin framework actually works.<br>
>> > simply means that we must fix it in order to catch any possible<br>
>> > regressions<br>
>> > we may introduce later (if not already).<br>
>> ><br>
>> > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent<br>
>> > into it and get feedback), we may not need to have example plugins.<br>
>> > However,<br>
>> > we can have fpb generating template plugin, with commented code in<br>
>> > there. If<br>
>> > you uncomment, you a get a comprehensive example of a working plugin.<br>
>> > To ensure that uncommented code would actually work, we must have a test<br>
>> > for<br>
>> > it (which would uncomment - run - ensure everything deploys).<br>
>> ><br>
>> > 3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest<br>
>> > to<br>
>> > think if there is a way to have tests, which would run such examples<br>
>> > against<br>
>> > pluggable framework for every change to the framework, so that we can<br>
>> > have<br>
>> > -1 right away if something goes wrong.<br>
>> ><br>
>> > I've started separate thread on general thoughts about backward<br>
>> > compatibility and multiple releases support, which actually affects<br>
>> > examples: [1]<br>
>> ><br>
>> > <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html</a><br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>> wrote:<br>
>> >><br>
>> >> Because it doesn't make much sense for a plugin developer to have<br>
>> >> scripts<br>
>> >> to build packages for installation on slave nodes. For default template<br>
>> >> it's<br>
>> >> better to have something minimalistic and the rest of the tasks<br>
>> >> commented,<br>
>> >> otherwise it may create a lot of confusion.<br>
>> >><br>
>> >> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov <<a href="mailto:ikutukov@mirantis.com" target="_blank">ikutukov@mirantis.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Talking about templates I mean plugins generated by FBP from the<br>
>> >>> `templates` folder using command you mentioned above.<br>
>> >>><br>
>> >>> Why not to extend (not replace) template-generated plugins with<br>
>> >>> additional data to provide right coverage?<br>
>> >>><br>
>> >>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>> wrote:<br>
>> >>>><br>
>> >>>> Ilya,<br>
>> >>>><br>
>> >>>> What do you mean by "templates" the plugin which is create by just<br>
>> >>>> "fpb<br>
>> >>>> --create plugin-name"?<br>
>> >>>> It doesn't cover enough, package installation and all range of tasks<br>
>> >>>> executions.<br>
>> >>>><br>
>> >>>> Thanks,<br>
>> >>>><br>
>> >>>> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov <<a href="mailto:ikutukov@mirantis.com" target="_blank">ikutukov@mirantis.com</a>><br>
>> >>>> wrote:<br>
>> >>>>><br>
>> >>>>> Igor, i completely agree, actually plugin examples is almost a<br>
>> >>>>> copy-paste.<br>
>> >>>>><br>
>> >>>>> The only thing i see useful in the built plugins example is the<br>
>> >>>>> ability<br>
>> >>>>> to point some code lines, discussing plugin design and writing<br>
>> >>>>> documentation. Why not to generate this examples automatically from<br>
>> >>>>> templates?<br>
>> >>>>><br>
>> >>>>> Also, as developer and administrator i love to use<br>
>> >>>>> examples/templates<br>
>> >>>>> where all essential settings and options are persist but commented<br>
>> >>>>> (e.g.<br>
>> >>>>> ProFTPD or Apache) and i could uncomment and copy-paste them not<br>
>> >>>>> being<br>
>> >>>>> afraid of typos. Also it allows to keep documentation actual and<br>
>> >>>>> head<br>
>> >>>>> documentation small. Duplication of inline documentation between<br>
>> >>>>> examples<br>
>> >>>>> and templates making things more weird and overshadows idea of<br>
>> >>>>> inline<br>
>> >>>>> documentation itself.<br>
>> >>>>><br>
>> >>>>> Eugeny, why not to run integration tests against plugins generated<br>
>> >>>>> from<br>
>> >>>>> templates? It's will be even better integration tests.<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky<br>
>> >>>>> <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>> wrote:<br>
>> >>>>>><br>
>> >>>>>> > and really lowering barriers for people who just begin create<br>
>> >>>>>> > plugins.<br>
>> >>>>>><br>
>> >>>>>> Nonsense. First, people usually create them via running `fpb<br>
>> >>>>>> --create<br>
>> >>>>>> plugin-name` that generates plugin boilerplate. And that<br>
>> >>>>>> boilerplate<br>
>> >>>>>> won't contain that changes.<br>
>> >>>>>><br>
>> >>>>>> Second, if people ain't smart enough to change few lines in<br>
>> >>>>>> `metadata.yaml` of generated boilerplate to make it work with<br>
>> >>>>>> latest<br>
>> >>>>>> Fuel, maybe it's better for them to do not develop plugins at all?<br>
>> >>>>>><br>
>> >>>>>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin<br>
>> >>>>>> <<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>> wrote:<br>
>> >>>>>> > +1 to maintain example plugins. It is easy enough and really<br>
>> >>>>>> > lowering<br>
>> >>>>>> > barriers for people who just begin create plugins.<br>
>> >>>>>> ><br>
>> >>>>>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn<br>
>> >>>>>> > <<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>><br>
>> >>>>>> > wrote:<br>
>> >>>>>> >><br>
>> >>>>>> >> Igor,<br>
>> >>>>>> >><br>
>> >>>>>> >> It seems you are proposing an IKEA approach to plugins. Take<br>
>> >>>>>> >> Fuel's<br>
>> >>>>>> >> example plugin, add in the current Fuel release, and then build<br>
>> >>>>>> >> it.<br>
>> >>>>>> >> We<br>
>> >>>>>> >> maintained these plugins in the past, but now it should a manual<br>
>> >>>>>> >> step<br>
>> >>>>>> >> to test it out on the current release.<br>
>> >>>>>> >><br>
>> >>>>>> >> What would be a more ideal situation that meets the needs of<br>
>> >>>>>> >> users<br>
>> >>>>>> >> and<br>
>> >>>>>> >> QA? Right now we have failed tests until we can decide on a<br>
>> >>>>>> >> solution<br>
>> >>>>>> >> that works for everybody.<br>
>> >>>>>> >><br>
>> >>>>>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky<br>
>> >>>>>> >> <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>><br>
>> >>>>>> >> wrote:<br>
>> >>>>>> >> > No, this is a wrong road to go.<br>
>> >>>>>> >> ><br>
>> >>>>>> >> > What if in Fuel 10 we drop v1 plugins support? What should we<br>
>> >>>>>> >> > do?<br>
>> >>>>>> >> > Remove v1 example from source tree? That doesn't seem good to<br>
>> >>>>>> >> > me.<br>
>> >>>>>> >> ><br>
>> >>>>>> >> > Example plugins are only examples. The list of supported<br>
>> >>>>>> >> > releases<br>
>> >>>>>> >> > must<br>
>> >>>>>> >> > be maintained on system test side, and system tests must<br>
>> >>>>>> >> > inject<br>
>> >>>>>> >> > that<br>
>> >>>>>> >> > information into plugin's metadata.yaml and test it.<br>
>> >>>>>> >> ><br>
>> >>>>>> >> > Again, I don't say we shouldn't test plugins. I say, tests<br>
>> >>>>>> >> > should<br>
>> >>>>>> >> > be<br>
>> >>>>>> >> > responsible for preparing plugins. I can say even more: tests<br>
>> >>>>>> >> > should<br>
>> >>>>>> >> > not rely on what is produced by plugins, since it's something<br>
>> >>>>>> >> > that<br>
>> >>>>>> >> > could be changed and tests start failing.<br>
>> >>>>>> >> ><br>
>> >>>>>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset<br>
>> >>>>>> >> > <<a href="mailto:scroiset@mirantis.com" target="_blank">scroiset@mirantis.com</a>><br>
>> >>>>>> >> > wrote:<br>
>> >>>>>> >> >> IMHO it is important to keep plugin examples and keep testing<br>
>> >>>>>> >> >> them,<br>
>> >>>>>> >> >> very<br>
>> >>>>>> >> >> valuable for plugin developers.<br>
>> >>>>>> >> >><br>
>> >>>>>> >> >> For example, I've encountered [0] the case where "plugin as<br>
>> >>>>>> >> >> role"<br>
>> >>>>>> >> >> feature<br>
>> >>>>>> >> >> wasn't easily testable with fuel-qa because not compliant<br>
>> >>>>>> >> >> with<br>
>> >>>>>> >> >> the last<br>
>> >>>>>> >> >> plugin data structure,<br>
>> >>>>>> >> >> and more recently we've spotted a regression [1] with<br>
>> >>>>>> >> >> "vip-reservation"<br>
>> >>>>>> >> >> feature introduced by a change in nailgun.<br>
>> >>>>>> >> >> These kind of issues are time consuming for plugin developers<br>
>> >>>>>> >> >> and<br>
>> >>>>>> >> >> can/must<br>
>> >>>>>> >> >> be avoided by testing them.<br>
>> >>>>>> >> >><br>
>> >>>>>> >> >> I don't even understand why the question is raised while fuel<br>
>> >>>>>> >> >> plugins<br>
>> >>>>>> >> >> are<br>
>> >>>>>> >> >> supposed to be supported and more and more used [3], even by<br>
>> >>>>>> >> >> murano [4]<br>
>> >>>>>> >> >> ...<br>
>> >>>>>> >> >><br>
>> >>>>>> >> >> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1543962" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1543962</a><br>
>> >>>>>> >> >> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1551320" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1551320</a><br>
>> >>>>>> >> >> [3]<br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html</a><br>
>> >>>>>> >> >> [4] <a href="https://review.openstack.org/#/c/286310/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/286310/</a><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn<br>
>> >>>>>> >> >> <<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>><br>
>> >>>>>> >> >> wrote:<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> Hi Fuelers,<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> I would like to bring your attention a dilemma we have here.<br>
>> >>>>>> >> >>> It<br>
>> >>>>>> >> >>> seems<br>
>> >>>>>> >> >>> that there is a dispute as to whether we should maintain the<br>
>> >>>>>> >> >>> releases<br>
>> >>>>>> >> >>> list for example plugins[0]. In this case, this is for<br>
>> >>>>>> >> >>> adding<br>
>> >>>>>> >> >>> version<br>
>> >>>>>> >> >>> 9.0 to the list.<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> Right now, we run a swarm test that tries to install the<br>
>> >>>>>> >> >>> example<br>
>> >>>>>> >> >>> plugin and do a deployment, but it's failing only for this<br>
>> >>>>>> >> >>> reason. I<br>
>> >>>>>> >> >>> should add that this is the only automated daily test that<br>
>> >>>>>> >> >>> will<br>
>> >>>>>> >> >>> verify<br>
>> >>>>>> >> >>> that our plugin framework actually works. During the Mitaka<br>
>> >>>>>> >> >>> development  cycle, we already had an extended period where<br>
>> >>>>>> >> >>> plugins<br>
>> >>>>>> >> >>> were broken[1]. Removing this test (or leaving it<br>
>> >>>>>> >> >>> permanently<br>
>> >>>>>> >> >>> red,<br>
>> >>>>>> >> >>> which is effectively the same), would raise the risk to any<br>
>> >>>>>> >> >>> member of<br>
>> >>>>>> >> >>> the Fuel community who depends on plugins actually working.<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> The other impact of abandoning maintenance of example<br>
>> >>>>>> >> >>> plugins<br>
>> >>>>>> >> >>> is that<br>
>> >>>>>> >> >>> it means that a given interested Fuel Plugin developer would<br>
>> >>>>>> >> >>> not be<br>
>> >>>>>> >> >>> able to easily get started with plugin development. It might<br>
>> >>>>>> >> >>> not be<br>
>> >>>>>> >> >>> inherently obvious to add the current Fuel release to the<br>
>> >>>>>> >> >>> metadata.yaml file and it would likely discourage such a<br>
>> >>>>>> >> >>> user.<br>
>> >>>>>> >> >>> In this<br>
>> >>>>>> >> >>> case, I would propose that we remove example plugins from<br>
>> >>>>>> >> >>> fuel-plugins<br>
>> >>>>>> >> >>> GIT repo if they are not maintained. Non-functioning code is<br>
>> >>>>>> >> >>> worse<br>
>> >>>>>> >> >>> than deleted code in my opinion.<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> Please share your opinions and let's decide which way to go<br>
>> >>>>>> >> >>> with this<br>
>> >>>>>> >> >>> bug[2]<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> [0]<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> <a href="https://github.com/openstack/fuel-plugins/tree/master/examples" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-plugins/tree/master/examples</a><br>
>> >>>>>> >> >>> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1544505" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1544505</a><br>
>> >>>>>> >> >>> [2] <a href="https://launchpad.net/bugs/1548340" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1548340</a><br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> Best Regards,<br>
>> >>>>>> >> >>> Matthew Mosesohn<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> __________________________________________________________________________<br>
>> >>>>>> >> >>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>>>> >> >>> Unsubscribe:<br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>><br>
>> >>>>>> >> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >> __________________________________________________________________________<br>
>> >>>>>> >> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>>>> >> >> Unsubscribe:<br>
>> >>>>>> >> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >><br>
>> >>>>>> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>>>> >> >><br>
>> >>>>>> >> ><br>
>> >>>>>> >> ><br>
>> >>>>>> >> ><br>
>> >>>>>> >> ><br>
>> >>>>>> >> > __________________________________________________________________________<br>
>> >>>>>> >> > OpenStack Development Mailing List (not for usage questions)<br>
>> >>>>>> >> > Unsubscribe:<br>
>> >>>>>> >> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>>>> >> ><br>
>> >>>>>> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>>>> >><br>
>> >>>>>> >><br>
>> >>>>>> >><br>
>> >>>>>> >> __________________________________________________________________________<br>
>> >>>>>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>>>> >> Unsubscribe:<br>
>> >>>>>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>>>> >><br>
>> >>>>>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>>>> ><br>
>> >>>>>> ><br>
>> >>>>>> ><br>
>> >>>>>> ><br>
>> >>>>>> > --<br>
>> >>>>>> > with best regards,<br>
>> >>>>>> > Stan.<br>
>> >>>>>> ><br>
>> >>>>>> ><br>
>> >>>>>> ><br>
>> >>>>>> > __________________________________________________________________________<br>
>> >>>>>> > OpenStack Development Mailing List (not for usage questions)<br>
>> >>>>>> > Unsubscribe:<br>
>> >>>>>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>>>> ><br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>> __________________________________________________________________________<br>
>> >>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>>>> Unsubscribe:<br>
>> >>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> __________________________________________________________________________<br>
>> >>>>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>>> Unsubscribe:<br>
>> >>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>>><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> __________________________________________________________________________<br>
>> >>>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>>> Unsubscribe:<br>
>> >>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> __________________________________________________________________________<br>
>> >>> OpenStack Development Mailing List (not for usage questions)<br>
>> >>> Unsubscribe:<br>
>> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> >>><br>
>> >><br>
>> >><br>
>> >> __________________________________________________________________________<br>
>> >> OpenStack Development Mailing List (not for usage questions)<br>
>> >> Unsubscribe:<br>
>> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>> > --<br>
>> > Mike Scherbakov<br>
>> > #mihgen<br>
>> ><br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>