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.



On Thu, Apr 17, 2014 at 10:14 AM, Terry Wilson <> wrote:

> >> A question about the fix from
> > 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 
> 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:
> 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
> _______________________________________________
> OpenStack-dev mailing list
OpenStack-dev mailing list

Reply via email to