<div dir="ltr">Glad to know I wasn't crazy in thinking it would completely break RHEL or OSes that backport things.  I tried pointing this out in the hopes it would get fixed before Icehouse dropped, but I guess I didn't yell loud enough or follow-up on my own.  Should target fixing for the first stable release as soon as reasonable.<br>
<br>Thanks,<br><br>Nate<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 10:14 AM, Terry Wilson <span dir="ltr"><<a href="mailto:twilson@redhat.com" target="_blank">twilson@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> A question about the fix from <a href="https://review.openstack.org/#/c/82931" target="_blank">https://review.openstack.org/#/c/82931</a><br>

<br>
> Also, how does this work for RHEL-based distros where they tend to backport<br>
> new kernel features? For instance vxlan support was added in the kernel for<br>
> RHEL6.5 which is 2.6.32-based... That changeset looks like it breaks Neutron<br>
> for ovs + vxlan on RHEL distros.<br>
<br>
> Nate<br>
<br>
The simple answer is that it doesn't work at all on RHEL. RHEL has backported upstream VXLAN support to the 2.6.32 kernel they use. It is fundamentally unsound to be checking kernel version numbers at runtime. Checking kernel version numbers in upstream code at runtime is just a fundamentally flawed thing to do. The only way those numbers mean anything is if they are in downstream packaging dependencies. There is also a lot of cruft that comes along with having to test all kinds of different things to ensure that the flawed check "works". It quickly gets very messy.<br>

<br>
It is almost universally accepted that if you want to test whether support exists for a feature, instead of trying to track version numbers across who knows how many options, you try to use the feature and then fail/fallback gracefully. I have a patch here <a href="https://review.openstack.org/#/c/88121/" target="_blank">https://review.openstack.org/#/c/88121/</a> which rips out all of the version checking and instead, at runtime when vxlan support is enabled, tries to create a temporary bridge/vxlan port and exits the openvswitch agent with a useful error message. With that said, I'm not a huge fan of modifying system state at startup just to test this. IMHO it might be better to just remove the check at startup altogether and error out with an informative message during the normal course when a VXLAN port cannot be created.<br>

<br>
Anyway, if people could take a look at the review:<br>
<br>
  <a href="https://review.openstack.org/#/c/88121/" target="_blank">https://review.openstack.org/#/c/88121/</a><br>
<br>
And perhaps have some discussion here, on list, about what we think is the best way to move forward with this, I'd be happy. :)<br>
<br>
Terry<br>
<br>
<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>
</blockquote></div><br></div>