Re: [openstack-dev] [neutron] [rhel7] minimal dnsmasq version
Thanks Ihar for sharing your thoughts! -- Andreas (irc: scheuran) On Mon, 2015-01-26 at 11:30 +0100, Ihar Hrachyshka wrote: Hi Andreas, On 01/26/2015 10:58 AM, Andreas Scheuring wrote: Hi Ihar, we're currently running stable/juno devstack on rhel7 base. But I see troubles to get it running on the master branch due to bug 1408297. The fix for this bug increases the minimal dnsmasq version for master branch up to 2.67. I also recognized the stable/juno item that leaves a warning if this version level is not reached - that's why it is working fine for us so far. You mentioned in the following thread http://lists.openstack.org/pipermail/openstack-dev/2015-January/053980.html , that redhat plans to backport the mac-ip matching feature to version 2.66. Not exactly. I only said that for some conservative distributions that strictly control any version bumps, simple bump of dnsmasq to 2.67 may be not an option, and hence they may consider backporting the feature they miss as an alternative. I haven't mentioned which route Red Hat will go though. You may be interested in tracking the following Red Hat bug to see how it goes: https://bugzilla.redhat.com/show_bug.cgi?id=1179756 Are you planning any additional Neutron code changes to also allow the version 2.66 or an older one of dnsmasq or may this new version for rhel come with the kilo rdo release? At least for IPv4 Use cases the 2.67 version is not required Yes, I have a patch in review to move the version check from DHCP agent to sanity_check tool [1]. I will update it today since it seems the issue gets a lot of traction and attention recently (f.e. see [2]). Note that at the moment, there is no RDO Kilo release yet. Though you may find some packages for Kilo in Delorean (RDO based on master) [3]. We hope that EL7 will receive an update for dnsmasq to allow it to serve IPv6 stateful subnets in the near future, as far as I know teams are actively working on delivering it. Once we get the update, we'll be ok to disable the warning in Juno [4] (in Red Hat repos, not upstream). [1]: https://review.openstack.org/148577 [2]: https://bugs.launchpad.net/bugs/1413042 [3]: http://209.132.178.33/repos/report.html [4]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/dhcp.py?h=stable/juno#n334 The only workaround I could imagine so far is to install a fedora package. Yes, that's a way to go for now. Sorry for any inconvenience due to that. Thanks! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] [rhel7] minimal dnsmasq version
Hi Ihar, we're currently running stable/juno devstack on rhel7 base. But I see troubles to get it running on the master branch due to bug 1408297. The fix for this bug increases the minimal dnsmasq version for master branch up to 2.67. I also recognized the stable/juno item that leaves a warning if this version level is not reached - that's why it is working fine for us so far. You mentioned in the following thread http://lists.openstack.org/pipermail/openstack-dev/2015-January/053980.html , that redhat plans to backport the mac-ip matching feature to version 2.66. Are you planning any additional Neutron code changes to also allow the version 2.66 or an older one of dnsmasq or may this new version for rhel come with the kilo rdo release? At least for IPv4 Use cases the 2.67 version is not required The only workaround I could imagine so far is to install a fedora package. Thanks! -- Andreas (irc: scheuran) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [rhel7] minimal dnsmasq version
Hi Andreas, On 01/26/2015 10:58 AM, Andreas Scheuring wrote: Hi Ihar, we're currently running stable/juno devstack on rhel7 base. But I see troubles to get it running on the master branch due to bug 1408297. The fix for this bug increases the minimal dnsmasq version for master branch up to 2.67. I also recognized the stable/juno item that leaves a warning if this version level is not reached - that's why it is working fine for us so far. You mentioned in the following thread http://lists.openstack.org/pipermail/openstack-dev/2015-January/053980.html , that redhat plans to backport the mac-ip matching feature to version 2.66. Not exactly. I only said that for some conservative distributions that strictly control any version bumps, simple bump of dnsmasq to 2.67 may be not an option, and hence they may consider backporting the feature they miss as an alternative. I haven't mentioned which route Red Hat will go though. You may be interested in tracking the following Red Hat bug to see how it goes: https://bugzilla.redhat.com/show_bug.cgi?id=1179756 Are you planning any additional Neutron code changes to also allow the version 2.66 or an older one of dnsmasq or may this new version for rhel come with the kilo rdo release? At least for IPv4 Use cases the 2.67 version is not required Yes, I have a patch in review to move the version check from DHCP agent to sanity_check tool [1]. I will update it today since it seems the issue gets a lot of traction and attention recently (f.e. see [2]). Note that at the moment, there is no RDO Kilo release yet. Though you may find some packages for Kilo in Delorean (RDO based on master) [3]. We hope that EL7 will receive an update for dnsmasq to allow it to serve IPv6 stateful subnets in the near future, as far as I know teams are actively working on delivering it. Once we get the update, we'll be ok to disable the warning in Juno [4] (in Red Hat repos, not upstream). [1]: https://review.openstack.org/148577 [2]: https://bugs.launchpad.net/bugs/1413042 [3]: http://209.132.178.33/repos/report.html [4]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/dhcp.py?h=stable/juno#n334 The only workaround I could imagine so far is to install a fedora package. Yes, that's a way to go for now. Sorry for any inconvenience due to that. Thanks! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
