Best Practices and Pitfalls for Building Products out of OpenDaylight

Size: px

Start display at page:

Download "Best Practices and Pitfalls for Building Products out of OpenDaylight"

Theodora Jean Briggs
6 years ago
Views:

1 Best Practices and Pitfalls for Building Products out of OpenDaylight Colin Dixon, TSC Chair, OpenDaylight Principal Software Engineer, Brocade Devin Avery, Sr Staff Software Engineer, Brocade

2 Agenda Agenda / Introduc5on Common Pi8alls Best Prac5ces Future Considera5ons Ques5ons

3 Our experience productizing OpenDaylight Brocade has released mul5ple versions of a controller for Brocade So far, based on Helium- SR1, Helium- SR2, and Helium- SR3 Rapidly approaching first Lithium- based release Running in produc5on with real customers We ve been successful in doing this even when incorpora5ng upstream changes Share our experiences - - pi8alls and successes

4 Common Pitfalls

5 wrong One way to build a release based on OpenDaylight Clone the OpenDaylight code (its public arer all!) Modify the code to customize / brand Add new code into the exis5ng projects for your proprietary logic Run the build Test, Ship and Sell it! Great, that was easy This is the first thing nearly everyone does

6 How (not) to build a custom fabric app and host tracker MyFabric App Flow Programming Host Tracking + MyFabric Δs Topology

7 This doesn t work! merely By cloning OpenDaylight code you have essen7ally forked the code! Synchronizing code with upstream can be difficult Your changes may not be accepted upstream (and you may not want them upstream) Pulling changes from upstream is likely to result in constant merge conflicts To avoid this pain, sync with upstream less oren => increases pain => even less oren Results in lower interac5on in community since code base is out of sync Don t get bug fixes, security patches, etc. OpenDaylight source code is licensed under EPL may put your proprietary changes at risk* *Note: we are not lawyers. Be sure to discuss any legal / licensing issues with your legal team

8 In Practice, this forking results in permanent divergence from upstream OpenDaylight That is, you no longer have an OpenDaylight-based product in most of the ways you and your customers care about.

9 Best Practices

10 Treat OpenDaylight as a Third-party Don t Download the OpenDaylight Source Code! Treat OpenDaylight as a collec5on read- only third- party ar5facts Reference ODL ar5facts, don t build them Leverage maven to access, maintain and manage your third- party dependencies for you For example: We don t recompile the basic java.u5l.arraylist Java class, we reference/use it We certainly don t modify the java.u5l.arraylist source code locally and build it

11 But OpenDaylight might not be a Third-party If you have modify OpenDaylight source code Push the changes upstream Wait for the next release major or stability Fold the changes in when bump your upstream versions What about cri5cal bugfixes/patches? Push the change upstream cherry-pick the patches into a locally- created clone of the upstream repo Build and release your own version of the relevant bundle(s) Note: this is complex and has risk, avoid it when possible.

12 Make changes to OpenDaylight upstream! We need OpenDaylight s core func5onality to succeed Otherwise our extensions, apps, etc. don t mamer You should Provide bug fixes Discuss new requirements Share implementa5ons, interfaces, extension points, etc. You will benefit from working more closely with upstream Get patches/fixes faster More likely have to have core OpenDaylight meet your needs faster Dave Neary on Swimming Upstream: hmp:// upstream

13 Leverage ODL Modularity / Isolate Proprietary Code Keep your proprietary code isolated to your own repositories, bundles, and Karaf features Leverage OSGi/Karaf/Maven to combine your code with OpenDaylight Leverage YANG/MD- SAL/Config system modularity to load proprietary implementa5ons into the modeling system OSGi is generally friendly with the EPL license* Exis5ng OpenDaylight Bundles Karaf MyFabric *Note: we are not lawyers. Be sure to discuss any legal / licensing issues with your legal team

14 Extension Example: Apps OpenDaylight Code/Bundles Your Proprietary Code/Bundles MyFabric App Flow Programming Host Tracking Topology

15 Extension Example: Replacing a Service Write an OSGi bundle that populates the Host Tracker YANG model OtherFabric App Exis5ng apps/services (either ODL or proprietary) will use the new implementa5on Flow Programming MyHostTracker Topology

16 Extension Example: Modifying an Existing Service OFVendorExt YANG OFVendorExt Java Flow Programming OtherFabric App Host Tracking Topology Augment exis5ng YANG models with new informa5on Provide Java code to extend behavior Requires Java extension points This is possible, but complex, needs thought and work Slides from ONS talk: hmp://colindixon.com/wp- content/uploads/2014/05/ YANG- good- bad- ugly- ONS pdf

17 Stabilize Development Environment No to Snapshots! Don t build using OpenDaylight snapshots! We don t compile against beta versions of the JRE, we compile against released versions! Snapshots are vola5le, and change constantly. Harder to determine if failures are related to your code, or snapshot change Customers want stable ar5facts (won t run on snapshots) If you use snapshots, then your release is 5ed directly to OpenDaylight release If you have 5me, you can compile dev versions of your code against dev versions of OpenDaylight to scope out poten5al issues

18 Stabilize Development Environment No to Snapshots! Ex: Mul5ple Proprietary Releases T = 0 T = 1 T = 2 T = 3 T = 4 Your Company s Ar5facts C- 1 C- 2 C- 3 C- 4 C- 5 Released OpenDaylight Ar5facts (Stable) He He- 1 He- 2 He- 3 He- 4 Ac5ve OpenDaylight Development (Vola5le) He- 1 Dev He- 2 Dev He- 3 Dev He- 4 Dev He- 5 Dev

19 The Result A product which references OpenDaylight ar5facts Proprietary code is isolated, and can be updated without affec5ng OpenDaylight code Also poten5ally avoid legal/licensing pain (ASK YOUR LAWYERS!) Changing versions of OpenDaylight code is just an update to a version in a pom file and some tes5ng Allows for a stable OpenDaylight controller on which to build proprietary implementa5ons

20 Future Considerations

21 Focus more on our users Core Developer App/Bus Log Dev REST API Dev Administrator Operator User Interface REST API App/Business Logic MD- SAL/YANG South Bound Business Logic Meta- tasks, e.g., install & upgrade

22 Focus more on our users Core Developer App/Bus Log Dev REST API Dev Administrator Operator User Interface REST API App/Business Logic MD- SAL/YANG South Bound Business Logic Meta- tasks, e.g., install & upgrade

23 Example: Easy Upgrades for Users Upgrades are a MUST! Customers will not accept a reinstall/reconfigure story Upgrades in OpenDaylight are an ajerthought Upgrades need to be a requirement No tes7ng in OpenDaylight today! Some problem areas / considera5ons Configura5on & Implementa5on stored together We have configura5on op5ons and implementa5ons (classes, etc) defined in the same file. Out- of- the- box and customer configura5ons stored together If customer change behavior then we can no longer safely upgrade (replace) the file. Need to merge! expensive Upgrades not always backwards compa5ble with previous version

24 Example: Minimizing risk of updates Currently everything needs to stay in one major monolithic release Helium- SR1 vs Helium- SR2 Interoperability / co- existence is not tested We find security vulnerability in OpenFlow Patch OpenFlow Rebuild everything Release Helium- SR2 with the fix We ve also pulled in poten5ally changes to everything else and changed all versions Exis5ng OpenDaylight Bundles (He- SR1) MD- SAL (He- SR1) Karaf (All SR1) OF (He- SR1) Exis5ng OpenDaylight Bundles (He- SR2) MD- SAL (He- SR2) Karaf (All SR2) OF (He- SR2) MyFabric w/he- SR1 MyFabric w/he- SR2

25 Example: Minimizing risk of updates We would like to to be able to upgrade only what changed Fix the OF vulnerability, release it, don t have to worry about changes in everything This would allow Faster delivery of fixes and features Lower risk to adop5ng fixes and features Some complexity in tes5ng, compa5bility matrices, avoiding huge versions skew, etc. Karaf (All SR1) MD- SAL (He- SR1) OF (He- SR1) Karaf (SR1 + OF fix) MD- SAL (He- SR1) OF (He- SR1+fix) This is all that changed!! MyFabric w/he- SR1 MyFabric w/he- SR1

26 Conclusions Treat OpenDaylight as a third-party (don t fork it!) Leverage Karaf, Maven, OSGi, YANG, Config system for modularity We still need to do better at user focus Where user is core developer, app developer, REST API developer, operator, administrator, etc. Easy upgrades, more modularity, version compa5bility, etc.

YANG Modeling: The Good, The Bad, and The Ugly

YANG Modeling: The Good, The Bad, and The Ugly Colin Dixon Technical Steering Committee Chair, OpenDaylight Principal Engineer, Brocade Talk Outline Really fast intro to the OpenDaylight Architecture What