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@xxxxxxxxx> > > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
