<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 4:36 AM, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Kevin,<br>
<br>
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.<br>
<br>
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].<br>
<br>
[1] <a href="https://review.openstack.org/#/c/206077/" target="_blank">
https://review.openstack.org/#/c/206077/</a><br>
[2] <a href="https://review.openstack.org/#/c/218486/" target="_blank">
https://review.openstack.org/#/c/218486/</a><br>
<br>
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].<br>
<br>
Many thanks,<br>
    Neil<div><div class="h5"><br>
<br>
<br>
On 31/08/15 06:53, Kevin Benton wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>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.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver <span dir="ltr">
<<a href="mailto:pcarver@paulcarver.us" target="_blank">pcarver@paulcarver.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's possible that I've misunderstood "Big Tent/Stadium", but I thought we were talking about enhancements to Neutron, not separate unrelated projects.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?
<div>
<div><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div>Kevin Benton</div>
</div>
</div>
</blockquote>
<br>
</div></div></div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>