[openstack-dev] [neutron] Testing Neutron with latest OVS
Russell Bryant
rbryant at redhat.com
Wed Jan 13 21:19:09 UTC 2016
On 01/13/2016 03:59 PM, Assaf Muller wrote:
> On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar <jlibosva at redhat.com> wrote:
>> Hi all,
>>
>> recently I was working on firewall driver [1] that requires latest
>> features in OVS, specifically conntrack support. In order to get the
>> driver tested, we need to have the latest OVS kernel modules on machines
>> running tests but AFAIK there is no stable "2.5 like" release of OVS yet.
>>
>> Facing the same problem OVN did in the past, I decided to try to steal
>> their solution and apply it in our Neutron repo [2]. Sean and Matthew
>> rightfully expressed worries about this approach on review of [2].
>>
>> So I'd like to bring this to a broader audience and ask for help or
>> suggestion on how to test such Neutron features that require some newer
>> versions.
>>
>> The first idea was to have an option to compile trunk ovs and use it in
>> particular jobs like functional one. That would bring faster development
>> of features going along with ovs features.
>
> I think we should use a newer OVS version that for the functional and
> fullstack jobs at the very least. This will enable us to test the OVS
> firewall driver you're working on, as well as the OVS ARP responder
> (Which was merged a long time ago, but lacks proper testing because
> it needs OVS 2.1+ and we gate using OVS 2.0).
>
> So, that's the problem. How we solve it is another manner - I was
> under the impression that compiling it is our only option. Right now
> OVN are compiling master, I think we should avoid that and compile a
> specific git hash instead so the gate won't break every time OVS
> breaks. Then, when OVS branch out 2.5, we can 'pin' on that.
FWIW, a 2.5 branch already exists, but hasn't been released yet. It
should only be receiving bug fixes at this point.
https://github.com/openvswitch/ovs/tree/branch-2.5
We compile from master since OVN is under such active development in
parallel, so that's really what we want. It also doesn't break anyone
but networking-ovn if there's an ovs issue. I probably wouldn't do that
for a more general voting neutron job.
> At that point we could perhaps switch to a packaged OVS off some
> sort of experimental repo.
Note that just using OVS 2.5 isn't enough. You must also have kernel
support for ovs+conntrack integration. That is in Linux 4.3+ or the
openvswitch kernel module included in the ovs tree.
networking-ovn's tempest job uses the openvswitch kernel module from ovs
master, as well. That seems to be working on the devstack jenkins nodes
just fine.
--
Russell Bryant
More information about the OpenStack-dev
mailing list