[ovs-dev] [PATCH ovn v4] Document process for compatibility between OVS and OVN.

Han Zhou zhouhan at gmail.com
Fri Oct 18 01:12:37 UTC 2019


On Thu, Oct 17, 2019 at 1:49 PM Mark Michelson <mmichels at redhat.com> wrote:
>
> On 10/16/19 4:36 PM, Han Zhou wrote:
> >
> >
> > On Tue, Oct 8, 2019 at 2:12 PM Mark Michelson <mmichels at redhat.com
> > <mailto:mmichels at redhat.com>> wrote:
> >  > +
> >  > +Developers who are making changes to both OVS and OVN at the same
> > time *must*
> >  > +contribute the OVS change first and ensure it is merged upstream
before
> >  > +submitting the OVN change. This way, OVN should never be in a state
> > where it
> >  > +will not compile.
> >  > +
> >
> > Hi Mark, I have a question here after reading your patch for release
> > documentation. If OVN is released more frequently than OVS, then there
> > is a chance that even developers make sure the related OVS change is
> > merged before OVN change, the next OVN release still can't compile with
> > the latest released OVS. It would only compile with the OVS master which
> > is not released yet. Is this a problem?
>
> Hi Han, We talked about this some during the OVN IRC meeting today, but
> I figure it's good to have the result of that documented here.
>
> The risks here are the following:
> 1) There may be a bug in OVS at the time that OVN is released.
> 2) Compiling against an arbitrary commit of OVS may make it difficult to
> reproduce/debug builds of OVN.
> 3) When distributing tarballs, people may be tempted to deploy the
> arbitrary OVS commit that OVN was compiled against rather than a
> supported released version.
>
> I'm going to downplay (1) somewhat. When it comes to compilation, the
> relevant bugs in OVS are limited to the library functions that OVS
> exports. The most common types of bugs in these functions would be
> discovered during OVN testing. And when it comes to the more insidious
> bugs (memory leaks, off-by-one errors, etc.), those aren't necessarily
> going to be any less likely to be fixed in a release vs. a non-release
> commit of OVS.
>
> Regarding (2), Justin suggested noting the OVS git commit necessary for
> building OVN. That way, we have an audit trail of what OVS commit was
> used for building any particular release of OVN.
>
> And I'm not sure about what to do about (3).
>

Thanks Mark for putting it together. I would be great if you could update
in the compatibility document, too.
For 3), what I understood was that we don't need to distribute the tarball,
but just note the commit id, so the problem shouldn't exist, correct? I
think it we can add this OVS commit id somewhere in the repo, and update it
whenever the dependency changes, i.e. a new commit is required for building
OVN.


More information about the dev mailing list