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