Open Stack

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 <twilson at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/ef9dee75/attachment.html>