> On 31 Aug 2015, at 13:36, Neil Jerram <neil.jer...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to