On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> > On 28 Aug 2015, at 14:08, Paul Carver <pcar...@paulcarver.us> wrote: > > > > Has anyone written anything up about expectations for how "Big Tent" or > "Neutron Stadium" projects are expected to be > installed/distributed/packaged? > > > > Seems like your questions below are more about extendability than e.g. > packaging. > > 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]). [1] http://governance.openstack.org/reference/projects/neutron.html [2] http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html#releases [3] https://review.openstack.org/#/c/217723/ > > 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. > > > > 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. > > > > 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. > > > 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? > > > > 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. > > 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. > > 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. > Ihar > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev