<div dir="ltr">Thanks for the insight.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 8, 2015 at 3:41 AM, Miguel Ángel Ajo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-family:Helvetica;font-size:14px">Correct, that’s the problem, what Kevin said should be the ideal case, but distros have<div>proven to fail satisfying this kind of requirements earlier.</div><div><br></div><div>So at least a warning to the user may be good to have IMHO.</div></div><span class="HOEnZb"><font color="#888888">
<div><div><br></div><div><span style="font-size:10pt">Miguel Ángel Ajo</span></div><div><br></div></div></font></span><div class="HOEnZb"><div class="h5">
<p style="color:#a0a0a8">On Thursday, 8 de January de 2015 at 12:36, Ihar Hrachyshka wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div>
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).<br>
<br>
<div>On 01/08/2015 05:25 AM, Kevin Benton
wrote:<br>
</div><blockquote type="cite"><div>
<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><br>
<div>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 type="cite"><div>
<div dir="ltr">
<div>
<div><span>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 type="cite"><div>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/145482</a><br>
<br>
</div></blockquote></span>
<div>Good catch, thanks for finding this Ihar!<br>
<br>
</div>
<span><blockquote type="cite"><div>
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>
</div></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><font color="#888888"><br>
<br>
Kyle<br>
<br>
</font></span></div>
<span><blockquote type="cite"><div>
/Ihar<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div></blockquote></span></div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div></blockquote></div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>
<div>Kevin Benton</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</div></blockquote><br>
</div><div><div>_______________________________________________</div><div>OpenStack-dev mailing list</div><div><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></div><div><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></div></div></div></span>
</blockquote>
<div>
<br>
</div>
</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>