<div dir="ltr">If the new requirement is expressed in the neutron packages for the distro, wouldn't it be transparent to the operators?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 6:57 AM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jan 7, 2015 at 8:21 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
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: <a href="https://review.openstack.org/145482" target="_blank">https://review.openstack.org/<u></u>145482</a><br>
<br></blockquote></span><div>Good catch, thanks for finding this Ihar!<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Obviously, we should communicate the revealed version dependency to deployers via next release notes.<br>
<br>
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.<br>
<br>
An alternative is to add a special check just for Juno that would WARN administrators instead of failing to start DHCP agent.<br>
<br>
Comments?<br>
<br></blockquote></span><div>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.<span class="HOEnZb"><font color="#888888"><br><br>Kyle<br> <br></font></span></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
/Ihar<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></span></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>