Open Stack

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>
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>
> 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://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://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/4ecba084/attachment.html>