Re: [libvirt] [PATCH 0/5] network: xmlns dnsmasq option passthrough

On Wed, Jul 17, 2019 at 05:38:51PM -0400, Cole Robinson wrote: > On 7/17/19 12:49 PM, Laine Stump wrote: >> On 7/14/19 8:03 PM, Cole Robinson wrote: >>> There's several unresolved RFEs for the <network> bridge >>> driver that are essentially requests to add XML wrappers >>> for underlying dnsmasq options. >>> >>> This series adds a dnsmasq xmlns namespace for <network> >>> XML that allows passing option strings directly to the >>> generated dnsmasq config file. It will allow motivated >>> users to work around libvirt until those types of RFEs >>> are properly implemented. >> >> This all looks like a reasonable facsimile of the qemu:commandline >> stuff, and it worked in my tests (including not creating any problems >> with all the existing networks I have on my test system). >> >> >> My one reservation would be that it will tend to discourage adding >> *supported* methods of configuring things that people will instead use >> this backdoor to implement. But on the other hand, it makes it possible >> to do new things without needing to wait for an officially supported >> method (which could take a very long time, or simply never happen, as >> we've seen). >> >> >> (Actually I for some reason thought we already *had* support for the >> specific example you used - CNAME records. I guess I had lumped it in >> with SRV and TXT records in my memory. It really should be >> straightforward to do, and should still be done, but that shouldn't stop >> this patch series from going in). >> >> >> This is for the entire series: >> >> >> Reviewed-by: Laine Stump <laine(a)laine.org&gt; > Thanks, I've pushed this now. > > Regarding the bigger point, I think it's worth considering whether we > should aim to expose every requested dnsmasq option as official XML or > not.

> We effectively have one network driver; there's an impl for vbox > and esx but they seem very basic. It doesn't look like we are going to > have another backend impl any time soon. I wouldn't rule it out. I can't remember where it was, but a few months ago I had a discussion with some folks precisely about replacing dnsmasq with new daemon(s). Primarily the purpose would getting a more secure solution modern solution written in a memory safe language. > Unless the requested option has some specific reason to be represented > in libvirt XML, like if another part of libvirt may need/want to > programmatically act on that data for some reason, maybe it's okay to > say that dnsmasq passthrough is the solution. Some examples might be > > * dhcp-option: https://bugzilla.redhat.com/show_bug.cgi?id=666556 > * auth-zone: https://bugzilla.redhat.com/show_bug.cgi?id=1690943 > * This bug has a lot of mentioned options: > https://bugzilla.redhat.com/show_bug.cgi?id=824573 Most of the stuff across these bugs is not really dnsmasq specific. It would be applicable to any DNS/DHCP service, so its just a matter of expressing it sensibly in the XML, so you're not tied to dnsmasq specific syntax.