Re: [libvirt] dnsmasq supporting RA instead of radvd patch

On 11/08/2012 02:30 PM, Gene Czarcinski wrote: > On 11/08/2012 01:55 PM, Eric Blake wrote: >> On 11/08/2012 08:26 AM, Doug Goldstein wrote: >>>>> I'm still not thrilled that you're pushing forward with requiring >>>>> 2.63 >>>>> + a few patches backported from 2.64 into 2.63 and only checking >>>>> against 2.63. >>> My point is if you're going to add a check for 2.63 >>> but really require 2.63 + 3 patches that Fedora has backported into >>> their 2.63 version which was your original proposal, this would cause >>> lots of headaches for every other distro out there unless they >>> backported those very same patches into 2.63. So better to wait for >>> 2.64 and go forward from there. libvirt works on and targets many more >>> systems than Fedora. >> Agreed. Upstream, libvirt should require 2.64. If Fedora (or any other >> distro) cares about shipping 2.63 + patches, then they can also patch >> their backport of libvirt to relax things to 2.63. But upstream cannot >> assume that 2.63 is patched. >> > Understood ... I think. > > 1. For RADVD, if dnsmasq version => 2.63, then dnsmasq will handle > the RA service. Otherwise, it will be radvd. My submitted patches > implement that. Granted, the patches are, more or less, chained > together and that will make life difficult. > > 2. Currently, there are NO version checks in the DHCP6 implementation > (all DHCPv6 stuff is in one patch file currently v6-7). If I > understand you correctly, you want dnsmasq version checks performed. > Some of this is simple and some is not so simple. > > 2a. If the dsnmasq version is => 2.64, all the DHCPv6 stuff is OK. > This check is fairly easy to do and I will try to get an > implementation in today so that things might move along. I would like > to see this as a minimum since I had modified and added to the tests > performed. Pulling a piece out of the middle will be "difficult." > > 2b. If dnsmasq version is <=2.63, then ?? > > -- fail/error out the dnsmasq startup because the xml specification > is invalid. > > -- or, just ignore the any DHCPv6 dhcp-range or dhcp-host > specifications but issue a syslog warning message that it is being > ignored because of the dnsmasq version. Since they are explicitly asking for this functionality, it's better to log an error and fail the network start. This will alert them that they aren't getting what they asked for in a very prominent manner. > -- or ? ... any suggestions? > > 3. I would like to make it "easy" for any system administratiors or > system maintainers who want DHCPv6 but also need to keep dnsmasq > 2.63. It it is too difficult, they will simply use dnsmasq 2.64test > or 2.64rc or 2.64 ... unlike libvirt, it only takes about 15 seconds > to rebuild the dnsmasq rpms. At some point in time in the not so > distant future, this becomes a non-issue ... it is the transition period. > > 3a. Do nothing! Screw it. If someone wants DHCPv6 support, then they > can get some version of dnsmasq 2.64 since it will be here "real soon > now". It has always been my contention that if someone wants libvirt > with DHCPV6 support, they can got the little extra to get a dnsmasq > that supports it. > > 3b. Add a configuration/compile-time options allowing 2.63. > > Right now I am inclined to do 3a. I agree. If you need 2.64 for proper DHCPv6 support, then just require that. Anybody who can upgrade to 2.63 can upgrade to 2.64 (my guess is that Fedora is unique in having 2.63 as its official version for any release, and that's only for F17 (it seems reasonable that we could get dnsmasq for F18 upgraded to 2.64, maybe even F17, with appropriate testing (and depending on the adventurousness index of the new Fedora dnsmasq maintainer :-)

> But, the question I have is what to do for 2b. The simplest way > (and this is my inclination for today) is to error out. I agree with that as well. > Right now I feel a little pressured because I am going to be > unavailable for the next week to ten days. -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list