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

Kevin Benton blak111 at gmail.com
Thu Jan 8 11:51:22 UTC 2015


Thanks for the insight.

On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo <majopela at 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 good to have IMHO.
>
> Miguel Ángel Ajo
>
> On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote:
>
>  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 upgrading dnsmasq version, and would just backport the needed
> fix to their 'claimed to 2.66' dnsmasq (common story in Red Hat world).
>
> On 01/08/2015 05:25 AM, Kevin Benton wrote:
>
> 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 <mestery at mestery.com> wrote:
>
>  On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka <ihrachys at 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 bump to 2.67
> in: https://review.openstack.org/145482
>
>  Good catch, thanks for finding this Ihar!
>
>
> Now, since we've already released Juno with IPv6 DHCP stateful support,
> and DHCP agent still has minimal version set to 2.63 there, we have a
> dilemma on how to manage it from stable perspective.
>
> Obviously, we should communicate the revealed version dependency to
> deployers via next release notes.
>
> Should we also backport the minimal version bump to Juno? This will result
> in DHCP agent failing to start in case packagers don't bump dnsmasq version
> with the next Juno release. If we don't bump the version, we may leave
> deployers uninformed about the fact that their IPv6 stateful instances
> won't get any IPv6 address assigned.
>
> An alternative is to add a special check just for Juno that would WARN
> administrators instead of failing to start DHCP agent.
>
> Comments?
>
>  Personally, I think the WARN may be the best route to go. Backporting a
> change which bumps the required dnsmasq version seems like it may be harder
> for operators to handle.
>
> Kyle
>
>
> /Ihar
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>  --
>  Kevin Benton
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150108/d2f1ac51/attachment.html>


More information about the OpenStack-dev mailing list