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.
Thanks, Nate On Thu, Apr 17, 2014 at 10:14 AM, Terry Wilson <twil...@redhat.com> wrote: > >> 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 > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
