I second Kyle on this, Quite more clear for users to see the version error message on the logs!
Edgar On 4/17/14, 7:23 AM, "Kyle Mestery" <mest...@noironetworks.com> wrote: >On Thu, Apr 17, 2014 at 9: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. >> > >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 >> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
