Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Kevin Benton
Thanks for the insight. On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo majop...@redhat.com wrote: Correct, that’s the problem, what Kevin said should be the ideal case, but distros have proven to fail satisfying this kind of requirements earlier. So at least a warning to the user may be

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Miguel Ángel Ajo
Now that I re-read the patch. Shouldn't the version checking need to be converted into a sanity check? Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 12:51, Kevin Benton wrote: Thanks for the insight. On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo majop...@redhat.com

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Ihar Hrachyshka
I agree, that is one thing we should not check in runtime. In ideal world, it wouldn't even check version number, but capabilities. I's not clear though whether we can be any smarter than that (we would need to run dnsmasq and real dhcp clients to check actual capabilities). /Ihar On

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Ihar Hrachyshka
The problem is probably due to the fact that some operators may run neutron from git and manage their dependencies in some other way; or distributions may suck sometimes, so packagers may miss the release note and fail to upgrade dnsmasq; or distributions may have their specific concerns on

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Miguel Ángel Ajo
Correct, that’s the problem, what Kevin said should be the ideal case, but distros have proven to fail satisfying this kind of requirements earlier. So at least a warning to the user may be good to have IMHO. Miguel Ángel Ajo On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Salvatore Orlando
I think it should be possible to have a sanity check like the following: 2.63 - sorry, that's not going to work =2.63, 2.67 - it kind of works but ipv6 is going to be messed up 2.67 - we're all right The runtime check on the dhcp agent is a startup check. Personally I think agents should run

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Ihar Hrachyshka
On 01/07/2015 03:21 PM, Ihar Hrachyshka wrote: Hi all, I've found out that dnsmasq 2.67 does not work properly for IPv6 clients when it comes to MAC address matching (it fails to match, and so clients get 'no addresses available' response). I've requested version bump to 2.67 in:

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Carl Baldwin
On Wed, Jan 7, 2015 at 9:25 PM, Kevin Benton blak...@gmail.com wrote: If the new requirement is expressed in the neutron packages for the distro, wouldn't it be transparent to the operators? I think the difficulty first lies with the distros. If the required new version isn't in an older

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-08 Thread Sean M. Collins
On Thu, Jan 08, 2015 at 11:53:24AM EST, Carl Baldwin wrote: On Wed, Jan 7, 2015 at 9:25 PM, Kevin Benton blak...@gmail.com wrote: If the new requirement is expressed in the neutron packages for the distro, wouldn't it be transparent to the operators? I think the difficulty first lies with

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-07 Thread Kevin Benton
If the new requirement is expressed in the neutron packages for the distro, wouldn't it be transparent to the operators? On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery mest...@mestery.com wrote: On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi all, I've found out

Re: [openstack-dev] [stable][neutron] minimal dnsmasq version

2015-01-07 Thread Kyle Mestery
On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: Hi all, I've found out that dnsmasq 2.67 does not work properly for IPv6 clients when it comes to MAC address matching (it fails to match, and so clients get 'no addresses available' response). I've requested version