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

Mon Nov 9 22:06:12 UTC 2020

On 11/9/20 8:03 AM, Ilya Maximets wrote:
> On 10/23/20 8: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.
> 
> There is one big problem with this way of handling things.
> Assuming that all commits (B, C, D, E and F) requires code changes in OVN
> for it to be compiled successfully.  Assuming that we cloned OVS at commit
> A to a special branch.  Now we're porting commit F without commits  B-E.
> At this point this special branch is the only version of OVS that could
> be used to build OVN, i.e. there is no any upstream OVS version that could
> be used to build OVN.
> In this case, we will have to maintain a special OVS branch for each OVN
> release or store somewhere the commit hash of OVS (from this special branch)
> per OVN release.  That is exactly same problem that we have right now except
> that we also need to maintain additional OVS branches.
> 
> I think, that having OVS as a git submodule should make life easier, as there
> will be only one version of OVS used to build OVN for every moment in time
> and users (people, who tries to build OVN) will not need to think about which
> version of OVS to build with.  Submodule version shift might be considered
> while implementing new features or before releasing a new version (or new
> stable version) of OVN to get bug fixes.

I'm not that familiar with git submodules, but does a submodule allow 
for easily building different versions of OVN against specific version 
of OVS? As an easy example, let's say that with OVN 20.12 we want to use 
OVS 2.14, and for OVN 20.14, we want to use OVS 2.15. If we switch 
between OVN branches, does that allow for automatic swapping of branches 
of the submodule as well?

> 
> Maintaining of a separate OVS repo and backporting patches there from the
> upstream OVS doesn't sound much different from just having required OVS
> bits copied to OVN main repo.  Copying is not good too, IMHO, because we
> will have to maintain copy of ovsdb idl code outside of OVS which is not
> a good thing taking into account its complexity.
> Another option is exporting everything from OVS and link with OVS libs.
> But again, this will require versioning of OVN, in terms that we will need
> to specify with which version of OVS libs each version of OVN will work or
> write lots of code in OVS to maintain backward compatibility for libraries.
> This sounds not that practical, since OVN actually uses a lot of OVS libs.

> 
>>
>>>
>>>
>>>> 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.
> 
> This option sounds like a slow migration of OVS libs to OVN repo.
> 
>>>>
>>>> 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
>>>
>>
>> _______________________________________________
>> dev mailing list
>> dev at openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
> 