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

Brian Haley haleyb.dev at gmail.com
Fri Oct 23 12:42:49 UTC 2020


On 10/22/20 3:31 PM, Mark Michelson wrote:
> 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.

This is what we do in Openstack Neutron.  For example, we have two gate 
jobs - one using released code, the other using the tip of the master 
branch.  It can take either a branch, tag, or commit, but it's currently:

     OVN_BRANCH: v20.06.1
     # TODO(jlibosva): v2.13.1 is incompatible with kernel 4.15.0-118, 
sticking to commit hash until new v2.13 tag is created
     OVS_BRANCH: 0047ca3a0290f1ef954f2c76b31477cf4b9755f5

and master:

     OVN_BRANCH: master
     OVS_BRANCH: master

Doing something like this would let you pick a point in time, and allow 
the user to override if they wish, like if the OS/kernel in question had 
an issue (as shown above).  It also keeps OVN out of keeping a copy if 
the OVS tree.

My $.02

-Brian


> 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/ 
> 
> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev


More information about the dev mailing list