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