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