Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
#ODSummit
Agenda
• Agenda / Introduc5on • Common Pi8alls
• Best Prac5ces • Future Considera5ons • Ques5ons
#ODSummit
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
#ODSummit
Common Pitfalls
#ODSummit
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
#ODSummit
wrong
How (not) to build a custom fabric app and host tracker
MyFabric App
Flow Programming
… …
Host Tracking + MyFabric Δs
… …
Topology
… …
#ODSummit
This doesn’t work!
• 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
#ODSummit
merely
#ODSummit
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.
Best Practices
#ODSummit
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
#ODSummit
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.
#ODSummit
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
#ODSummit Dave Neary on Swimming Upstream: hmp://www.slideshare.net/nearyd/swimming-‐upstream-‐45666354
• 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*
Karaf
Leverage ODL Modularity / Isolate Proprietary Code
#ODSummit
Exis5ng OpenDaylight Bundles
*Note: we are not lawyers. Be sure to discuss any legal / licensing issues with your legal team
MyFabric
Extension Example: Apps
MyFabric App
Flow Programming
… …
Host Tracking
… …
Topology
… …
#ODSummit
OpenDaylight Code/Bundles
Your Proprietary Code/Bundles
Extension Example: Replacing a Service
OtherFabric
App
Flow Programming
… …
MyHostTracker
… …
Topology
… …
#ODSummit
Write an OSGi bundle that populates the Host Tracker YANG model
Exis5ng apps/services (either ODL or proprietary) will use the new implementa5on
Extension Example: Modifying an Existing Service
OtherFabric App
Flow Programming
… …
Host Tracking
…
Topology
…
#ODSummit
OFVendorExt YANG
OFVendorExt Java
• 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-‐2015.pdf
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
#ODSummit
Stabilize Development Environment – No to Snapshots!
#ODSummit
He-‐1 He-‐2 He-‐3 He
C-‐2 C-‐3 C-‐5 C-‐1
T = 0 T = 1 T = 2 T = 3 T = 4
He-‐2Dev
He-‐3 Dev
He-‐4 Dev
He-‐1 Dev
Your Company’s Ar5facts
Released OpenDaylight Ar5facts (Stable)
Ac5ve OpenDaylight Development (Vola5le)
C-‐4
Ex: Mul5ple Proprietary Releases
He-‐4
He-‐5 Dev
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
#ODSummit
Future Considerations
#ODSummit
Focus more on our users
#ODSummit
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
✔✔✔ ✔✔
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
✔✔✔ ✔✔
Focus more on our users
#ODSummit
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
#ODSummit
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
#ODSummit
Karaf (All SR1)
Exis5ng OpenDaylight Bundles (He-‐SR1)
MyFabric w/He-‐SR1
OF (He-‐SR1)
MD-‐SAL (He-‐SR1)
Karaf (All SR2)
Exis5ng OpenDaylight Bundles (He-‐SR2)
MyFabric w/He-‐SR2
OF (He-‐SR2)
MD-‐SAL (He-‐SR2)
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.
#ODSummit
Karaf (All SR1)
MyFabric w/He-‐SR1
Karaf (SR1 + OF fix)
MyFabric w/He-‐SR1
OF (He-‐SR1+fix)
MD-‐SAL (He-‐SR1)
This is all that changed!!
OF (He-‐SR1)
MD-‐SAL (He-‐SR1)
#ODSummit
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.