Hi,

Dnia piątek, 27 lutego 2026 15:17:21 czas środkowoeuropejski standardowy Jakub Libosvar pisze:
> Hi all,
>
> I wanted to bring this topic up for a discussion again.
>
> I’ve been working on a Neutron feature [1] for some time, the feature
> requires the BGP support in OVN. The functional job currently uses
> a moving OVN branch based on the OVN LTS version - which is 24.03 -
> almost 2 years old. I tried to change this and requested a patch to
> switch to using a pinned OVN mostly for two benefits:
>   - we won’t get gate broken if a bad patch is backported to the branch-24.03
>   - I get the BGP features needed for the work on [1]
>
> The patch was denied to keep the policy we set on ourselves - ie. to go with the branch based
> on the OVN LTS version. The workaround was to skip multiple tests that rely on the OVN
> changes specific to BGP. This is not ideal as now majority of the functionality is
> not tested and we’re just waiting for the LTS release, which may bring some surprises.

I didn't know that we have such policy TBH. And I know that we have periodic tempest job which is testing with OVS and OVN from master branch daily: https://zuul.opendev.org/t/openstack/builds?job_name=neutron-ovn-tempest-full-multinode-ovs-master&skip=0
In other scenario jobs AFAIR OVS and OVN is installed from the packages provided by distro.

>
> This was a concrete example but if we put it into a more general situation, in Neutron
> we heavily rely on OVN and its features and any development of a potential feature that
> requires some work in OVN gets cumbersome because we can’t validate our code against
> OVN until the point a next OVN LTS version is released, which in the worst case scenario
> can take up to 2 years.
>
> Hence I propose a change and use a pinned hash from the OVN tree that
> is updated on two occasions:
>   - A next OVN version is released (non-LTS)
>   - We’re developing a feature that relies on bleeding edge OVN - then we pick a good
>     hash and pin to it in the functional job definition (not in the scripts)
>
> This would apply solely to the functional tests because tempest jobs
> can define their own OVN version and unit tests should be isolated from the used
> OVN version, and only to the master branch - because that is the development branch
> after all.
>
> Such a change brings multiple benefits, we won’t need to skip tests if
> the required functionality is not present in current OVN version and have
> the development go smoother.
> We may uncover issues in OVN early.
> We will not get a broken gate if a change containing a bug is backported to OVN stable branch.
>
> At this point I can’t see any benefit of using the moving LTS branch, but if there
> is one please bring it up here.
> 
> Any thoughts on this?

IMO it makes perfect sense to use newer OVN in functional tests job.

>
> Thanks,
> Kuba
>
> [1] https://opendev.org/openstack/neutron-specs/src/branch/master/specs/2025.2/ovn-bgp-integration.rst
> [2] https://review.opendev.org/c/openstack/neutron/+/961243
>
>


--
Slawek Kaplonski
Principal Software Engineer
Red Hat