> On Dec 13, 2018, at 2:06 PM, Mark Michelson <[email protected]> wrote:
Thanks for pulling this together, Mark. Here are some of my initial thoughts: > 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 This was the direction I was originally thinking, but upon further reflection, the number of repos we'd need (at a minimum: OVS, OVSDB, common utitliies, library code, and OVN) and the cross-dependencies makes this seem prohibitively hard. (Or at least prohibitively hard in the short- to medium-term.) > 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 I think one of our immediate goals should be that we allow the "committers" list of the OVS and OVN projects to grow separately. This approach won't help that. > 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. I think this would very likely lead to difficulties on keeping them updated. > 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] This seems like the most attractive option at this point. Unfortunately, OVN really is dependent on OVS as a library, and this is when submodules make sense. We'll be able to grow and release the projects separately, and we should be able to make this change pretty quickly. That will give us more time to see whether it makes sense to break OVS into separate components later. I'd be curious to get others' opinions--especially if they have more recent git submodule experience than I have. --Justin _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
