> 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. > 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. 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
