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/[email protected]/
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
