[ovs-dev] OVN-OVS build compatibility, take 2

Mark Michelson mmichels at redhat.com
Thu Oct 22 19:31:06 UTC 2020


Hi,

In today's OVN meeting [1], Numan brought up that he had proposed an OVN 
patch [2] that deals with a compilation error that occurred after 
updating to the latest OVS master. This sparked a discussion about the 
process behind OVN/OVS build compatibility.

After OVN was split from OVS last year, the attitude with regard to 
build compatibility was that

1) Only devs are likely to be building OVN, so building against the 
latest and greatest OVS should be acceptable.
2) Since OVN links to OVS's libraries statically, it's fine if the 
version of OVS used to build OVS is different from the version of OVS 
that OVN runs against.

After nearly a year of having OVN separated, we've come to the 
realization that this may not be the best way to do things. Reasons why 
include

1) The "latest and greatest" OVS could actually be a very unstable 
mid-version build of OVS. Since OVN is released more often than OVS, 
this necessitates OVN releases being built against an unstable version 
of OVS.
2) Debugging OVN problems that are rooted in OVSDB or OVS libraries can 
be tremendously difficult. Bisecting OVN commits likely requires 
changing the OVS commit to build against. This effectively gives two 
moving targets for tracking the issue.
3) OVN includes "non-public" headers in OVS.

Based on the meeting today, proposed ideas for fixing this are

1) Move headers from ovs's lib/ folder to include/ since they are 
consumed by OVN, an external program.
2) Anchor OVN builds on a specific release of OVS rather than just using 
the latest OVS release.

The problem with (2) of course is that there may be a bug in the OVS 
version we select. Or we could require a feature be merged in OVS in 
order for OVN to function properly. To deal with that, there were a 
couple of ideas mentioned in the meeting

1) Clone the version of OVS that we rely on into a repo on ovn-org, and 
then include that as a submodule. If we need a specific bugfix or new 
feature, we can backport the fixes to this clone after first getting 
them pushed to OVS.

2) If possible, we can backport the fix or feature into a local file in 
OVN and use that version of the function/feature rather than what's in OVS.

What are people's thoughts on the matter? Any other suggestions for how 
to tackle this problem?

Thanks,
Mark Michelson

[1] 
http://eavesdrop.openstack.org/meetings//ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-10-22-17.16.log.html
[2] 
https://patchwork.ozlabs.org/project/ovn/patch/20201022155339.300989-1-numans@ovn.org/



More information about the dev mailing list