[ovs-dev] OVN-OVS build compatibility, take 2
mmichels at redhat.com
Fri Oct 23 18:56:58 UTC 2020
On 10/23/20 8:42 AM, Brian Haley wrote:
> On 10/22/20 3:31 PM, Mark Michelson wrote:
>> 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
>> 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
During our meeting we discussed something similar. If I understand your
proposal correctly, the problem is that we won't have as much control
over which changes in OVS we consume. For instance, if we start by
anchoring OVN development to OVS at commit A, we may find a month later
that there is a bug we need to fix. In the meantime, commits B, C, D,
and E have gone into OVS. So when we merge our bug fix, we are doing so
as commit F. If we then point OVN to commit F of OVS, then we are also
consuming commits B, C, D, and E, which we don't want. By cherry-picking
commit F to a separate branch, we know that we are only getting commit F
on top of commit A.
>> 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?
>> Mark Michelson
>> dev mailing list
>> dev at openvswitch.org
More information about the dev