Open Stack

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 
> <mailto:mestery at mestery.com>> wrote:
>
>     On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka
>     <ihrachys at redhat.com <mailto: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
>         <mailto: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
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
> Kevin Benton
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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