Open Stack

Thanks, Kevin and Ihar, for your advice on this.  I think I know what to do with my change now, and I hope I haven't too much hijacked the previous direction of this thread.

Regards,
      Neil


From: Kevin Benton
Sent: Monday, 31 August 2015 16:38
To: OpenStack Development Mailing List (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 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.Jerram at metaswitch.com<mailto:Neil.Jerram at 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 <pcarver at paulcarver.us<mailto:pcarver at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150831/9d9b5d6d/attachment.html>