Open Stack

On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> > On 28 Aug 2015, at 14:08, Paul Carver <pcarver at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150828/40d5178e/attachment.html>