[ovs-dev] OVN/OVS code split: POC

Han Zhou zhouhan at gmail.com
Wed Feb 27 07:38:59 UTC 2019


On Tue, Feb 26, 2019 at 1:13 PM Mark Michelson <mmichels at redhat.com> wrote:
>
> On 2/22/19 4:45 PM, Ben Pfaff wrote:
> > On Fri, Feb 22, 2019 at 04:15:27PM -0500, Mark Michelson wrote:
> >> On 2/22/19 4:01 PM, Ben Pfaff wrote:
> >>> On Mon, Feb 18, 2019 at 09:50:56AM -0500, Mark Michelson wrote:
> >>>> Hi everyone,
> >>>>
> >>>> I have completed a *rough* POC of an OVN/OVS code split. You can find it at
> >>>> https://github.com/putnopvut/ovn.git
> >>>>
> >>>> Please take a look at the README file since that highlights how the split
> >>>> was done, as well as some known issues.
> >>>>
> >>>> My attitude towards this repo is that it is a throwaway prototype. It
> >>>> essentially proves the concept that OVN can include OVS as a git subtree,
> >>>> while not really attempting to do a production-ready job of
> >>>> doing so. There is a lot of unfinished work.
> >>>
> >>> It looks like the sort of thing I'd expect to see.
> >>>
> >>> One thing I don't expect to see for a first cut or an nth cut is
> >>> perfection.  Stuff in corner cases is going to be broken.  That's the
> >>> nature of big changes.  We'll fix them as we notice them.
> >>>
> >>> The manpages.mk errors are from the rule in the Makefile that tries to
> >>> rebuild manpages.mk.  That's why touching it helps, since it keeps the
> >>> Makefile from trying to rebuild it.
> >>>
> >>> What do you think is your next step?
> >>>
> >>
> >> Hi Ben,
> >>
> >> Thanks for the reply. My current step is to get buy-in for this approach. If
> >> people have suggestions for improvement or outright disapproval (with
> >> logical reasoning of course), then I'll iterate and try to take those
> >> suggestions into consideration.
> >>
> >> If people are 100% cool with the approach I've taken, then the next step
> >> will be to come up with a plan to officially split the OVN code out from
> >> OVS. It'll need a plan for a few reasons:
> >>
> >> 1) We'll need to get an official OVN repo to perform the work in.
> >
> > That is easy.  I (or any other OVS committer) can create one under the
> > openvswitch organization on github.  I'm happy to do so whenever you
> > like, even now.
> >
> > There's also the "ovn-org".  Justin is the sole owner of that org
> > currently.  I guess he'll probably add more people.
> >
> > (It's easy to transfer repos between orgs, so no worries about that.)
> >
> >> 2) We'll essentially need to have a "freeze" on OVN development during the
> >> split. Otherwise, changes that occur between the start of the split and the
> >> completion of the split could get lost. Or it will require some porting of
> >> the changes between repos. Either way, not a fun task.
> >
> > Good point.
> >
> >> 3) We'll want to have testing plans in place. Tests will need to be focused
> >> on ensuring that OVN works with compatible versions of OVS. Compatibility is
> >> something that we've avoided trying to make official stances on, but that
> >> could be a sub-item to perform here as well.
> >
> > Do you plan to make a proposal here?
>
> I'm hesitant to for a couple of reasons. One is that I've worked with
> enough software to know that guarantees *will* be broken. For instance,
> we might attempt a policy like "we will guarantee that the current
> version of OVN will work with the current version of OVS as well as the
> previous minor version". But things like security issues and other
> critical fixes could result in that guarantee being broken.
>
> Also, it's very possible that new features introduced in OVN mean that
> it is "compatible" with the previous version of OVS but runs in a
> crippled capacity due to missing requirements in OVS.
>
> I think the appropriate policy here would be a best-effort to maintain
> compatibility with the current version of OVS as well as the previous
> minor version. Compatibility with any older versions of OVS cannot be
> guaranteed. Any exceptions to the best-effort approach will be
> documented in some file in the OVN repo.
>
> >
> > Are you more concerned about OVN or OVS for testing?  It's easy for OVN
> > to accidentally add a dependency on some later-than-intended version of
> > OVS or OVSDB (although maybe just testing with the intended version
> > helps?) but it's also easy for OVS to accidentally make some change that
> > breaks OVN.
>
> I think I'm more concerned about OVS. OVN developers will be well aware
> of the changes that they are making in both repos. OVS developers have
> the potential to introduce changes that compile in OVS but cause
> breakage in OVN. It's an understandable problem since some OVS
> developers may not even be aware that OVN depends on OVS.
>
> CI can be used to ensure that OVN compiles against supported versions of
> OVS and that tests still pass. This way, OVN devs can be notified if
> there's a new breakage in OVN and fix it as soon as possible.
>
>
> >
> >> 4) We'll want to be sure we're all on the same page regarding when the OVN
> >> split occurs. Will we do it at the same point that OVS 2.12 is being
> >> released, or will we do it as soon as possible and have OVN start its own
> >> versioning independent of OVS immediately?
> >
> > Is there any advantage to waiting, once we're ready?
>
> If OVN is versioned independently from OVS, then there's no real reason
> to wait for an OVS release. We can do it whenever we're ready.
>
> >
> > This might be a good time to increment the OVS major number to 3.0.
> >
> >> Once all of the above are determined, then I think it's a matter of
> >> essentially re-doing what I've done already, but in a more official capacity
> >> (i.e. using an official repo, making more coherent commits, ensuring builds
> >> work across platforms). Once there is a functioning repo in which work can
> >> be done, we can work on the finer details (i.e. removing additional
> >> irrelevant files, reworking documentation). And once all of that is done,
> >> then I think the administrative details can become important (i.e.
> >> determining committers, updating websites, mailing lists, etc.)
> >
> > Oh my, it'll take a long time to get that right.
> >
> > I wonder whether OVN should adopt a more "modern" workflow, such as
> > Github pull requests instead of emails.
> >
>
> I'd certainly be OK with that. The main advantage I see of a more
> "modern" workflow is the ability to gate merges based on things like CI
> passes.
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

I agree with the approach. I just want to add that there are some
reverse dependencies from OVS to OVN, probably only in tests. At least
one example is that ovsdb-cluster.at uses ovn to do tests. It can be
solved with some changes, but it is definitely some work there.

Apart from this, I have just some trival problem/questions. I went
ahead to clone the repo and try to play with it to get some real
feelings. However, I encountered an error when doing make:
make[4]: *** No rule to make target 'lib/dhparams.c', needed by
'lib/dhparams.lo'.  Stop.

This same error occurred when I tried to make in the ovs sub directory.

Another question is regarding git subtree. I didn't see the ovs sub
directory as a git subtree in your repo. I am not familiar with git
subtree, but it seems the ovs sub directory is included directly in
the repo? Or how can I confirm it is a subtree instead of a part of
the ovn repo?

In addition, I noticed that the changes are based on an old version in
Apr 2018. I wonder why not starting with the latest master, but maybe
that doesn't matter too much for a POC.

Thanks,
Han


More information about the dev mailing list