[ovs-dev] OVN/OVS Split POC: version 2

Mark Michelson mmichels at redhat.com
Wed Apr 17 20:31:33 UTC 2019


On 4/12/19 6:02 PM, Ben Pfaff wrote:
> On Tue, Mar 26, 2019 at 04:15:07PM -0400, Mark Michelson wrote:
>> I've once again rolled another OVN/OVS split version. It can be found at
>> https://github.com/putnopvut/ovn_mk2.git
>>
>> The main changes between this and the old split POC are as follows:
>>
>> * This is based on a much newer build of OVS master. Therefore, build errors
>> people had with dhparams.c *should* be cleared up.
>>
>> * This fixes errors with manpages.mk generation/checking, so there is no
>> need to do a pointless `touch` of manpages.mk during the build process.
>>
>> * In many cases, rather than hard-coding paths to OVS, we use variables.
>> This isn't universally applied, but it's used for the locations of C
>> headers, libraries, and manpages.
>>
>> Please give this a look and let me know what you think.
> 

Sorry for the late reply Ben. Your response was filtered to a folder I 
wasn't expecting.

> This builds cleanly for me when srcdir==builddir.  I get a failure if I
> use a separate builddir, as is my usual habit, e.g.:
> 
>      blp at sigill:~/nicira/ovn_mk2/_build(2)$ make -j10
>      make  all-recursive
>      make[1]: Entering directory '/home/blp/nicira/ovn_mk2/_build'
>      Making all in ovs
>      make[2]: Entering directory '/home/blp/nicira/ovn_mk2/_build/ovs'
>      make  all-recursive
>      make[3]: Entering directory '/home/blp/nicira/ovn_mk2/_build/ovs'
>      Making all in datapath
>      make[4]: Entering directory '/home/blp/nicira/ovn_mk2/_build/ovs/datapath'
>      make[5]: Entering directory '/home/blp/nicira/ovn_mk2/_build/ovs/datapath'
>      make[5]: Leaving directory '/home/blp/nicira/ovn_mk2/_build/ovs/datapath'
>      make[4]: Leaving directory '/home/blp/nicira/ovn_mk2/_build/ovs/datapath'
>      make[4]: Entering directory '/home/blp/nicira/ovn_mk2/_build/ovs'
>      make[4]: Leaving directory '/home/blp/nicira/ovn_mk2/_build/ovs'
>      make[3]: Leaving directory '/home/blp/nicira/ovn_mk2/_build/ovs'
>      make[2]: Leaving directory '/home/blp/nicira/ovn_mk2/_build/ovs'
>      make[2]: Entering directory '/home/blp/nicira/ovn_mk2/_build'
>      make[2]: *** No rule to make target '../ovs/ovsdb/libovsdb.la', needed by 'utilities/ovn-nbctl'.  Stop.
>      make[2]: *** Waiting for unfinished jobs....
>      make[2]: Leaving directory '/home/blp/nicira/ovn_mk2/_build'
>      make[1]: *** [Makefile:3335: all-recursive] Error 1
>      make[1]: Leaving directory '/home/blp/nicira/ovn_mk2/_build'
>      make: *** [Makefile:2205: all] Error 2
>      blp at sigill:~/nicira/ovn_mk2/_build(2)$
> 
> But that's a minor thing and I expect you can fix it easily.  I think
> this is pretty much ready to go.  What do you think should be the next
> step?

You're correct that this can be fixed easily. It just requires a few 
extra lines to be added to the configure script.

As far as next steps go, I think that we need to do these changes in an 
official capacity. What does this entail?

First, we need an official repo to perform the changes in. I suspect 
that you would need to provide this. Whether this is in the openvswitch 
github project or a new one is a potential matter of discussion.

Next, we need to declare a date/time to officially switch over to 
performing OVN development in the new repo. There are a couple of 
reasons for this:
* Merges to OVN code should halt while the work is done. This way, there 
is no chance of losing OVN changes as part of the merge.
* Contributors need to be aware of when they need to switch over to 
using the new repo for development.
* Contributors may want to get changes they are working on up for review 
prior to the switchover to prevent having to re-do their changes in the 
new repo.

I think those are the big things that need to be done next. After that, 
we can make incremental changes in the new repo, even if they are 
somewhat large. The other major things to discuss are 
administrative/policy changes. Those can also wait until the code split 
is complete.

> 



More information about the dev mailing list