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

Ilya Maximets i.maximets at ovn.org
Tue Nov 10 16:38:48 UTC 2020 

On 11/9/20 11:06 PM, Mark Michelson wrote:
> 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?

In short, submodule tied up to the commit hash.

In more details:
Once you did 'git submodule add https://github.com/openvswitch/ovs.git' and
commit the result, you will have commit like this:
---
commit e73ff80db8326519ef94733fad4fd38cab01eeed (HEAD -> master)
Author: Ilya Maximets <i.maximets at ovn.org>
Date:   Tue Nov 10 17:19:29 2020 +0100

    Add openvswitch submodule.
    
    Signed-off-by: Ilya Maximets <i.maximets at ovn.org>

diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 000000000..f0d1f8cbe
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "ovs"]
+       path = ovs
+       url = https://github.com/openvswitch/ovs.git
diff --git a/ovs b/ovs
new file mode 160000
index 000000000..193995f81
--- /dev/null
+++ b/ovs
@@ -0,0 +1 @@
+Subproject commit 193995f81c07347847190b03bd9da23948d497a6
---

It's a simple commit and the whole submodule directory looks like a single
commit hash of an ovs repo.  And this is part of the OVN repo.  So, while
checking out branch-20.14 of OVN, you will checkout the exact version of a
submodule that described by this meta file named 'ovs'.
By default, git will not change the version of submodule while checking out
different branch in OVN, but you could run 'git submodule update --init' and
it will be.

So, with your example.  Assuming OVN 20.12 branch has submodule version OVS 2.14
and OVN 20.14 has submodule version OVS 2.15.  Assuming that we're on OVN 2.12
branch and current version of OVS submodule is 2.14:
- git checkout branch-20.14
- At this point OVS is still on version 2.14, but we have a diff like this:
  $ git diff
  diff --git a/ovs b/ovs
  index 193995f81..2eebece5a 160000
  --- a/ovs
  +++ b/ovs
  @@ -1 +1 @@
  -Subproject commit 193995f81c07347847190b03bd9da23948d497a6
  +Subproject commit 2eebece5a3b5fe8b5d546f13c7d79af29324bf99
  ---
  This diff is because committed version of submodule for this branch is different.
- git submodule update --init
  Submodule path 'ovs': checked out '193995f81c07347847190b03bd9da23948d497a6'
- Now OVS version in submodule is 2.15 and there is no more diff.

To shift current version of a submodule to a new version you need to cd into
'ovs' folder and checkout required version.  After that you need to cd back
and see the hash change in a git diff.  At this point you just need to commit
this new hash.

That was a lousy description on how to work with submodules, here is a great and
easy documentation: https://git-scm.com/book/en/v2/Git-Tools-Submodules

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

More information about the dev mailing list