[libvirt] dnsmasq supporting RA instead of radvd patch
gene at czarc.net
Thu Nov 8 20:36:47 UTC 2012
On 11/08/2012 02:59 PM, Laine Stump wrote:
> 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
>>>>>> + 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 :-)
OK, it is done ... now I just have to rework the submitted patches:
dnsmasq-RA >-2.63, otherwise radvd. DHCPv6 dnsmasq >=2.64 and error out
if not. .. it only took a few lines of code.
>> 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 at redhat.com
More information about the libvir-list