On 01/13/2016 03:59 PM, Assaf Muller wrote: > On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar <jlibo...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev