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

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.

-- 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.

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.

Right now I feel a little pressured because I am going to be unavailable for the next week to ten days.