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

Mark Michelson mmichels at redhat.com
Wed Feb 27 13:44:21 UTC 2019


On 2/27/19 2:38 AM, Han Zhou wrote:
> 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.

Thanks for pointing this out. It makes sense that the tests use OVN 
since ovsdb clustering is targeted at OVN's use.

> 
> 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 is a problem that Numan ran into as well when he tested it out. I 
haven't seen it on my setup so it's been difficult to tell what's going 
on. I'll talk about this a bit more below.

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

This is because the error is happening when the ovs Makefile is invoked. 
The ovn Makefile.am has "SUBDIRS = ovs" in it, so it calls into the ovs 
Makefile as part of the build process.

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

This is one of the ways that git subtrees differ from git submodules. 
git submodules are essentially "links" to a remote repo, whereas 
subtrees are essentially copies of a separate repo. With subtrees there 
is no git metadata that indicates that the subdirectory comes from a 
remote repo. There is no way to tell from inspection alone that the ovs/ 
subdirectory is a subtree. It must be documented as part of the 
project's policy.

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

Yes, this was a mistake on my part. I decided to use a personal clone of 
ovs as the basis for the split. I did not realize that I had not rebased 
against upstream master and went forth with the split using the old code.

I did not realize I was using such an old version until Numan reported 
having an issue with the dhparams.c file. It was then that I realized 
how out of date the POC was. Unfortunately, just updating the ovs/ 
subtree wouldn't be enough, because the top-level ovn files were also 
horribly out of date. In order to update properly, I'd need to redo the 
split from scratch using an up-to-date version of ovs. Having done the 
split once, it probably wouldn't take too long to get it completed if I 
had to do it over again, but I figured I could get some early opinions 
on the matter even if it's an old version and not in the greatest shape.

Given that I've now had multiple reports of the build being a problem 
due to the dhparams.c error, it is probably worth my while to re-do the 
split on a newer version of ovs master. For one thing, it would be a 
good indicator of how long the split would take when we do it for real.

> 
> Thanks,
> Han
> 



More information about the dev mailing list