1. Discussing an OVS/OVN Split
And Maybe Answering Some Questions
Mark Michelson
Senior Software Developer
Red Hat

2. Why do we want a split?

3. Why do we want to split? Different development paces
OVN’s adoption rate is increasing
Users of OVN want faster turnaround
Users of OVN want incremental updates to OVN only
Different audiences, both developers and users
OVS developers: hardware engineers, kernel engineers
OVN developers: cloud engineers
Different dependencies
OVS: kernel modules
OVN: Haskell and Rust coming soon (?)

4. How do we perform the split?

5. Split Goals Make OVN and OVS be able to exist as independent projects
Run version A of OVS and version B of OVN without issue
Don’t intermix dependencies of OVN with OVS
Make OVN and OVS be able to release at independent cadences
We may wish to release OVN more or less often than OVS currently releases
Version numbering of OVN and OVS can diverge
AVOID PAIN
Don’t make it difficult to build OVS or OVN
Don’t make it difficult to test
Don’t make it difficult to maintain compatibility
Continuous integration should be used to catch mistakes early

6. Split Mechanics Phase 1: Expected for OVS 2.11 release in 2019
Package separation
Maintaining runtime compatibility
Phase 2: Expected for OVS 2.12 release in 2019
Code separation
Maintaining code compatibility

7. Part 1: Packaging separation
OVN is currently a subpackage of OVS
When repackaging OVN, the latest OVS package will also be required.
Therefore, users cannot upgrade OVN without also upgrading OVS.

8. Part 1: Packaging separation
Create separate packaging of OVN and OVS
Allows for OVN to be rebuilt and upgraded without also updating OVS.
Static linking of libraries means no issues with code incompatibility.

9. Part 2: Maintaining Runtime Compatibility
What happens when you upgrade OVN but don’t upgrade OVS?
Mismatch between OpenFlow match fields and actions
Assumptions about database fields that may be present
There must be ways to test at runtime if a feature is present or not.
We may actually have these means already, but enforcement of their usage will be required.

10. Phase 1 Benefits
We can distribute new builds of OVN without requiring any changes to OVS.
OVN can be upgraded without the need to also upgrade OVS.
However…
We don’t have a way of versioning OVN independently of OVS. OVN must still release at the same pace as OVS.

11. Part 3: Code Separation AKA The big one
What is shared between OVN and OVS?
C code
Memory allocation, hashmaps, IP address manipulation, etc.
Test utilities
M4 functions
Test programs
Build utilities
Documentation

12. Part 3: Code Separation What is shared between OVN and OVS? OVSDB
C code
Memory allocation, hashmaps, IP address manipulation, etc.
Test utilities
M4 macros
C and python test utilities
Miscellaneous utilities
checkpatch

13. Part 3: Code Separation Strategy 1: Full separation
Definition: OVS and OVN live in separate repos.
Any resources that are shared between both code bases needs to live in a repo that both OVS and OVN can access.

14. Part 3: Code Separation Strategy 1: Full separation Lots of git repos:
OVS C library
OVS test library
OVSDB
OVS
Contains vswitchd and OVS tests
OVN
Contains ovn-northd, ovn-controller, and OVN tests
Potentially lots of repos to push changes to for certain types of enhancements
OVS developers inconvenienced by repo reorganization
Soooooo many versions of things to keep up with.

15. Part 3: Code Separation Strategy 1: Full separation
Alternate repo setups are possible
Example:
OVS C libraries and OVSDB repo
OVS/OVN test repo
Contains all OVS and OVN tests and their shared utilities
OVS
OVN
Helps make the test situation a bit less complicated.

16. Part 3: Code Separation Strategy 2: Clones
Create a clone of the OVS repo for OVN.
Remove OVN code from the OVS repo.
Remove OVS code from the OVN repo.
Both have copies of the common code between them.
Definitely the easiest option.
But it also means potential divergence between OVN and OVS implementations of common routines. Vigilance would be necessary to make changes in both repos if there is a common bug. Would be hell for OVSDB.

17. Part 3: Code Separation Strategy 3: Logical separation
Definition: continue to use one git repo
Restructure directories to clearly indicate OVS, OVN, and shared resources between the two.
Use separate configure scripts and Makefiles for OVS and OVN, allowing each to be built independently.
But does git make this easy? Multiple projects in one git repo? How does tagging work?

18. Part 3: Code Separation Strategy 4: git submodule
Similar to strategy 1, in that OVS and OVN live in separate repos.
With this, OVN uses OVS as a git submodule. This rocks the boat least with regards to the OVS repo. It mostly just will look like all the OVN code has been removed.
git submodules are not the easiest things to work with, though.

19. Part 4: Maintaining Code Compatibility
How do we ensure that OVN continues to compile when it and OVS are being developed independently?
Examples:
A public function gains a new parameter
A structure gets new fields added to it (or other ABI changes)
OVN needs to be able to compile whether using a version before the change or after.
This could affect OVS as well if common C libraries end up in their own repo.

20. Part 4: Maintaining Code Compatibility
Ideas:
Configure-time checks for certain features, functions, struct fields, etc.
Version checks to conditionally compile code.
No matter how it’s done, it will require discipline and LOTS of testing to ensure that nothing gets broken.

21. So let’s discuss!

22. THANK YOU plus.google.com/+RedHat facebook.com/redhatinc
linkedin.com/company/red-hat
twitter.com/RedHatNews
youtube.com/user/RedHatVideos