Open Stack

> On 31 Aug 2015, at 13:36, 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].
> 

I believe Dnsmasq class does not intend to maintain a stable API, so the method that you override may change its name at any moment, breaking your subproject. The fact that the method name starts with underscore only suggests that it’s not the best approach to extend it. If you would like to base your driver on top of Dnsmasq, ideally, you would work with neutron community to detect pieces that are absolutely needed for your subproject, and work on defining a stable API that you can then reuse.

But if the only thing you need is to pass some custom configuration to dnsmasq, then you may already have all you need. Specifically, you could configure dnsmasq_config_file = in dhcp_agent.ini to point to a file that contains all your custom settings.

Ihar