Open Stack

>> A question about the fix from https://review.openstack.org/#/c/82931

> Also, how does this work for RHEL-based distros where they tend to backport
> new kernel features? For instance vxlan support was added in the kernel for
> RHEL6.5 which is 2.6.32-based... That changeset looks like it breaks Neutron
> for ovs + vxlan on RHEL distros.

> Nate

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.

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 https://review.openstack.org/#/c/88121/ 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.

Anyway, if people could take a look at the review:

  https://review.openstack.org/#/c/88121/

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. :)

Terry