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
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-num...@ovn.org/
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
