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

Mark Michelson mmichels at redhat.com
Wed Feb 27 18:41:43 UTC 2019


On 2/27/19 10:14 AM, Aaron Conole wrote:
> Hi Mark,
> 
> Mark Michelson writes:
> 
>> 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.
> 
> Thanks for starting this.
> 
> As others have noted, the git subtree is a strange sort of requirement.
> Do you think it makes sense to have the ovs makefile install the
> requisite utilites and man-page templates in known locations instead?
> In that fashion, there's no need to have a separate clone of ovs, we can
> just ensure that we've done an install of OVS and the build system can
> search for the dependencies.
> 
> I think it might just be as simple as adding the needed pieces to the
> various existing automake variables (scripts_SCRIPTS, scripts_DATA,
> maybe MAN_FRAGMENTS, etc).  If that is acceptable and works, you could
> include it as a temporary patch in the OVN split directory until it gets
> merged to OVS mainline.  That way, we could apply to our tree, rather
> than needing a separate clone of the ovs repo, and when other downstream
> projects build there's no need to clone the repo again.  rpms and debs
> could have -dev(el) versions that install those files.
> 

OK I see what you're saying. The idea would be that an installation of 
OVS would put the parts OVN depends on into specific locations on the 
filesystem, and OVN could then use those "installed" files as needed.

I suppose that there would be some default locations for these files. If 
the files are installed to custom locations, then OVN could be told 
these custom locations at configure time.

> I'm looking forward to the next spin, and hope that it will be based off
> a newer cut of the openvswitch repository.
> 
> Have you thought about using the `git filter-branch` facility to try and
> preserve history, as well?  I don't know how important you think it is
> to try and keep the history, but it could be a way to take an existing
> OVS repository and cut out all the non-OVN commits (which is a huge
> number of them, true).  It might be a lot of work for not enough gain,
> though.  Just a fleeting thought.

Jiri Benc had brought up git filter-branch back during the early 
planning stages as a mechanism for maintaining history. One issue he had 
brought up, IIRC, is that with git filter-branch, you're forced to 
maintain the same directory structure. In my POC, I moved the ovn/ 
subdirectory to the top level. Also, I think the amount of work to 
filter out all of the non-OVN commits would not be worth it, especially 
since classifying commits as being related to OVN vs. not related to OVN 
can be murky at times.

> 
>> Please let me know your thoughts on this.
>> Thanks,
>> Mark Michelson
> 



More information about the dev mailing list