Hi everyone,
Last week at OVScon, I gave a talk about the mechanics of the OVS/OVN
split. One lingering question is the actual method by which the code for
OVN should get split from OVS.
To sum up, OVN and OVS share several resources in the OVS repo right now:
* OVSDB
* C libraries (hmap, packets, etc.)
* Test utilities (m4 macros, C and Python programs)
* Other utilities (stuff in build-aux, checkpatch.py)
Because of this, there's not a natural way to separate OVN's source code
out to its own repo.
To get the ball rolling, here are some ideas I thought of, with some
pros and cons for each one.
1) Separate components in separate repos
In this approach, we separate the current code into multiple repos.
Clearly, there would be an "ovs" and "ovn" repo, and the resources they
share would exist in one or more other repos. The number of these
"utility" repos required is up for debate.
+ Separates components into logical areas.
+ Nothing is repeated between repos.
- Requires separate versioning of shared components, potentially
creating difficulty when calculating dependencies.
- Effects OVS developers as much as it does OVN developers.
- Difficulty: Hard
2) Logically separate OVN from OVS, but remain in one repo
For this approach, we modify the directory structure of the current OVS
repo but don't remove anything. We create separate configure scripts and
makefiles for OVS and OVN so that they can be built separately.
+ Difficulty: Easy
- Does not *really* separate OVN and OVS from each other
- Potentially inconveniences OVS developers since we mess with the
directory structure of the repo.
- I'm not really sure how you version multiple projects in one git repo
3) The clone approach.
For this approach, create a clone of the OVS repo for OVN. In the OVS
repo, delete the OVN parts. In the OVN repo, delete the OVS parts.
+ Difficulty: Easy
+ Genuinely separates OVS and OVN into their own repos
- Lots of repeated code between the OVN and OVS repos
- Extra cognitive load when fixing bugs in code common to OVS and OVN
(i.e. I have to fix the same bug in multiple repos). Though it may be
possible to automate this.
4) git submodule
For this approach, we create a clone of hte OVS repo for OVN. In the OVS
repo, delete the OVN parts. In the OVN repo, delete everything that is
not directly related to OVN. In the OVN repo, we add OVS as a git submodule.
+- Difficulty: Medium
+ Adds zero overhead for developers of OVS
- git submodules have a bit of a shaky history[1]
These are ideas I've thought about. What are your thoughts on the
matter? Do you have experience with such an endeavor? Can you think of
ways to split the code that are not mentioned above?
Thanks,
Mark Michelson
[1] I'm only familiar with git submodules as a concept. I don't have any
experience having to deal with them. However, when I mentioned it as a
possibility during my talk at OVScon, I saw some people in the audience
physically cringe.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
