Discussing an OVS/OVN Split And Maybe Answering Some Questions Mark Michelson Senior Software Developer Red Hat mmichels@redhat.com

Why do we want a split?

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 (?)

How do we perform the split?

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

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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?

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.

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.

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.

So let’s discuss!

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