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

[Daniel P. Berrangé]

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 at laine.org>
> 
> 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|