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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
