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

Brian Haley haleyb.dev at gmail.com
Tue Oct 27 21:47:17 UTC 2020

On 10/23/20 2:56 PM, Mark Michelson wrote:
> On 10/23/20 8:42 AM, Brian Haley wrote:
>> 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
> Thanks Brian,
> 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.

Hi Mark,

Understood.  I guess my thought was that there are two scenarios - 
master and stable branches.  Moving forward from A -> F on a stable 
branch should be Ok as it typically wouldn't do something to break any 
APIs, right?  Master is more volatile and going to break things eventually.


>>> 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