>> 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 

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


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


OpenStack-dev mailing list

Reply via email to