1 / 22

Discussing an OVS/OVN Split

This discussion explores the OVS/OVN split, goals, mechanics, its benefits, and various code separation strategies to maintain compatibility.

gwetherell
Download Presentation

Discussing an OVS/OVN Split

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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

More Related