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
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
