<div dir="ltr">On Mon, Nov 18, 2013 at 12:50 AM, Pedro Roque Marques <span dir="ltr"><<a href="mailto:pedro.r.marques@gmail.com" target="_blank">pedro.r.marques@gmail.com</a>></span> wrote:<br><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-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Does it address the catch-22 problem that a Neutron reviewer asks for the plugin to be accepted upstream into devstack as pre-condition for acceptance whether a devstack reviewer as for the plugin to be upstreamed into Neutron first ?</div>

</blockquote><div><br></div><div>Yes, that is the intention.  However, you have to do the work of integrating it, it isn't going to go into the existing gate right off, if ever.  Mark's message this morning[1] lays it out from their point of view.  He mentions using the CI third party testing integration [2] in the 'Testing Requirements' section.  Ideally, you get that running with a trunk DevStack plus your plugin against the Nova and Neutron branches with your contrail plugin/mods.</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">
<div style="word-wrap:break-word"><div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">Also, DevStack does not install support services that are not packaged in the underlying distro.  Look at Docker's split between the support service(s) that start before stack.sh runs and the parts that specifically configure Nova.<br>
</div>
</div></blockquote><div><br></div></div>Can you please elaborate as to what are "support services" in this context ?</div><div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"></div></div></blockquote>
</div></div></div></blockquote><div>Things required of the running environment that are not shipped with the OS need to be in place before stack.sh runs.  i.e., you are compiling a kernel module.  DevStack's workflow is not an appropriate place to do that.  As another example, we have an install script for Docker that takes care of their service installation and startup that is up to the end-user ot have run before running stack.sh.  This keeps us (DevStack) out of the business of trying to maintain something we {can not/do not} test.</div>
<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"><div style="word-wrap:break-word"><div>The patches that are being applied by the script have been submitted for review. Using a patch approach is helpful in attempting to demonstrate that the resulting code works against the master branch of Nova/Neutron.</div>
</div></blockquote><div><br></div><div>The OpenStack methodology for this is to fork the repo and create a branch of the source tree with your patch and test against that.</div><div><br></div><div>For the gate testing, DevStack actually does NONE of the source branch setup work.  A CI component names Zuul does all of that, pulling branches and repos as it requires to set up the correct environment.  Patching the source trees after that destroys the integrity of what Gerrit/Jenkins/devstack-gate thinks it is testing.</div>
<div> </div><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"><div style="word-wrap:break-word">
<div><div>Can you please suggest a sequence of steps... ?</div><div>I understand that it makes sense to follow the plugin documentation specified above. That would be the first step. But it is not clear to me how to break it down further while having something that is still functional.</div>
</div></div></blockquote><div><br></div><div>If you get it running as a plugin and there are no changes required to the existing DevStack files then you are done.  Any changes to DevStack indicate a shortcoming in the plugin interface and may need to be generalized anyway.</div>
<div> </div><div>dt</div><div><br></div><div>[1] <a href="http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg08700.html">http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg08700.html</a></div><div>
[2] <a href="http://ci.openstack.org/third_party.html">http://ci.openstack.org/third_party.html</a></div><div><br></div></div><div><br></div>-- <br><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br>

</div></div>