Open Stack

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" <mestery at noironetworks.com> wrote:

>On Thu, Apr 17, 2014 at 9: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.
>>
>
>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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev