<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.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">> On 28 Aug 2015, at 14:08, Paul Carver <<a href="mailto:pcarver@paulcarver.us">pcarver@paulcarver.us</a>> wrote:<br>
><br>
> Has anyone written anything up about expectations for how "Big Tent" or "Neutron Stadium" projects are expected to be installed/distributed/packaged?<br>
><br>
<br>
Seems like your questions below are more about extendability than e.g. packaging.<br>
<br></blockquote><div><br></div><div>I agree, though I will say that your project is listed as "release:independent" [1]. This means that networking-sfc will NOT release when neutron and neutron-[fwaas, lbaas, vpnaas] release Liberty, but can release whenever it desires. This would be when the code is complete and the team has decided a release should be made. The process for handling this release is documented here [2] (though wait for that to refresh based on the review which merged here [3]).<br><br>[1] <a href="http://governance.openstack.org/reference/projects/neutron.html">http://governance.openstack.org/reference/projects/neutron.html</a><br>[2] <a href="http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html#releases">http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html#releases</a><br>[3] <a href="https://review.openstack.org/#/c/217723/">https://review.openstack.org/#/c/217723/</a><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> In particular, I'm wondering how we're supposed to handle changes to Neutron components. For the networking-sfc project we need to make additions to the API and corresponding additions to neutronclient as well as modifying the OvS agent to configure new flow table entries in OvS.<br>
><br>
> The code is in a separate Git repo as is expected of a Stadium project but it doesn't make sense that we would package altered copies of files that are deployed by the regular Neutron packages.<br>
><br>
<br>
Of course you should not ship you custom version of neutron with your sub-project. Instead, you should work with neutron team to make sure you have all needed to extend it without duplicating efforts in your project.<br>
<br>
> Should we be creating 99%+ of the functionality in filenames that don't conflict and then making changes to files in the Neutron and neutronclient repos to stitch together the 1% that adds our new functionality to the existing components? Or do we stage the code in the Stadium project's repo then subsequently request to merge it into the neutron/neutronclient repo? Or is there some other preferred way to integrate the added features?<br>
><br>
<br>
I presume that all sub-projects should use their own python namespace and not pollute neutron.* namespace. If that’s not the case for your sub-project, you should migrate to a new namespace asap.<br>
<br>
If there is anything missing in neutron or neutronclient for you to integrate with it, then you should work in those repositories to get the extension hooks or features you miss, and after it’s in neutron, you will merely utilise them from your sub-project. Of course it means some kind of dependency on the progress in neutron repository to be able to estimate feature plans in your sub-project.<br>
<br></blockquote><div>I'll second Ihar here. If you have dependencies in other projects, those need to be worked in so they can be consumed by networking-sfc.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ihar<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><br></div></div>