Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

No, I wouldn't consider that to be monkey-patching. That's something that we have a pluggable driver interface for. As Ihar pointed out, you will have to be careful maintaining it since the class you are subclassing may move or alter the '_build_cmdline_callback' method, but that isn't a huge

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

On 08/31/2015 01:50 AM, Kevin Benton wrote: The purpose of big tent isn't to have a bunch of sub-projects change the neutron core APIs and reference in ways they deem necessary. That will lead to a terrible user experience where the core functionality changes depending on which sub-projects are

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

(not for usage questions) Reply To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging No, I wouldn't consider that to be monkey-patching. That's something that we have a pluggable driver interface

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

Hi Kevin, I currently have an example of this kind of thing that I'm working on, and I'd appreciate hearing your view on what is the best solution. My requirement was to change some of the command line options with which the DHCP agent invokes Dnsmasq. My first implementation of this was in

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

> On 31 Aug 2015, at 13:36, Neil Jerram wrote: > > Hi Kevin, > > I currently have an example of this kind of thing that I'm working on, and > I'd appreciate hearing your view on what is the best solution. > > My requirement was to change some of the command line

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

If your sub-project requires changes to the Neutron API or client, then those need to be made in the in the main neutron and client projects. monkey-patching or completely replacing components of the main neutron project is not the way to go. The purpose of big tent isn't to have a bunch of

[openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

Has anyone written anything up about expectations for how Big Tent or Neutron Stadium projects are expected to be installed/distributed/packaged? 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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

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.

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

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?

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

It's possible that I've misunderstood Big Tent/Stadium, but I thought we were talking about enhancements to Neutron, not separate unrelated projects. We have several efforts focused on adding capabilities to Neutron. This isn't about polluting the Neutron namespace but rather about adding