Open Stack

> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: Wednesday, January 13, 2016 9:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Testing Neutron with latest OVS
> 
> 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.
>
We had a similar issue with testing ovs with dpdk. We have been building ovs
>From git for the last year in our third party ci with no real issues related to the compilation.
For our ci we specify the commits to use via the settings file of our devstack plugin
And rev the fixed versions via gerrit review to update the default commit id/tag/branch.

One of the ideas that I have been thinking about over the last month or two is do we
Want to create a dedicated library file in devstack to support compilation and installation
Of ovs. Both networking-ovs-dpdk and networking-ovn currently maintain code to build
And deploy ovs to suit our needs but there are other examples of features that require new
Ovs versions. The conntrack driver we are discussing requires ovs 2.5+,
the learn action driver requires 2.4+, networking-sfc requires 2.3.6+ and both networking-ovs
and networking-ovs-dpdk need to be able to support deploying master to consume newly developed
features in ovs/ovn.

So perhaps we should pool our resources and add single library that is configurable to support
All our usecases? 
Regards
sean

> --
> Russell Bryant
> 
> ________________________________________________________________________
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev