On Thu, Apr 17, 2014 at 9:14 AM, Terry Wilson <[email protected]> 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. >
I'm not sure throwing an error and exiting when the first VXLAN port creation happens is a good idea. On the other hand, I agree with Maru that executing an invasive check at runtime is also potentially challenging. But given the realities of the situation here (backports, etc.), I think we don't have a choice. The runtime check at startup is cleaner and allows the agent to fail right away with a clear error message. Thanks, Kyle > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
