[libvirt] dnsmasq supporting RA instead of radvd patch

[Gene Czarcinski]

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
>>>>>> 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 :-)

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