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 deal.
What I wouldn't want to see is a sub-project modifying core components of the OVS agent or ML2 plugin and claiming that it is still using the OVS agent or ML2 plugin. On Mon, Aug 31, 2015 at 4:36 AM, Neil Jerram <neil.jer...@metaswitch.com> 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 options with which > the DHCP agent invokes Dnsmasq. My first implementation of this was in > core Neutron, triggered by an interface driver method or property, and you > can see various versions of that at [1]. Then I realized that I could also > do this using an out-of-core subclass of Dnsmasq, and you can see that > approach at [2]. > > [1] https://review.openstack.org/#/c/206077/ > [2] https://review.openstack.org/#/c/218486/ > > I guess the question is: would you consider [2] to be a monkey-patch, in > the sense that you had in mind when writing below? If it is, I guess that > means that I should continue pursuing the approach of [1]. > > Many thanks, > Neil > > > > On 31/08/15 06:53, Kevin Benton wrote: > > 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 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 loaded. Sub-projects should add new > extensions or write drivers/plugins for various backends. > > On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver <pcar...@paulcarver.us> > wrote: > >> 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 >> capabilities that Neutron currently is missing. >> >> My concern is that we need to add to the Neutron API, the Neutron CLI, >> and enhance the capabilities of the OvS agent. I'm under the impression >> that the "Neutron Stadium" allows us to do this, but I'm fuzzy on the >> implementation details. >> >> Is the "Neutron Stadium" expected to allow additions to the Neutron API, >> the Neutron client, and the Neutron components such as ML2 and the OvS >> agent? >> >> >> >> __________________________________________________________________________ >> 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 >> > > > > -- > Kevin Benton > > > > __________________________________________________________________________ > 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 > > -- Kevin Benton
__________________________________________________________________________ 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
