[ovs-dev] OVN-OVS build compatibility, take 2
mmichels at redhat.com
Thu Oct 22 19:31:06 UTC 2020
In today's OVN meeting , Numan brought up that he had proposed an OVN
patch  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
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
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?
More information about the dev