[ovs-dev] OVN-OVS build compatibility, take 2
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:
>>> 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
> 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.
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?
>>> Mark Michelson
>>> dev mailing list
>>> dev at openvswitch.org
More information about the dev