Hi Kuba, On 2/27/26 9:57 AM, Slawek Kaplonski wrote:
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.
I don't think we ever decided on a policy, although I remember discussing it at a PTG, would have to go through the notes. Like Slawek mentioned, we have other jobs in the periodic/experimental queues using main and compiling, can we do the same for functional so we get coverage here? -Brian
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/o... [2] https://review.opendev.org/c/openstack/neutron/+/961243