new best practices and pitfalls for building products out of … · 2017. 12. 14. · best...

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)


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


Karaf (SR1 + OF fix)


OF (He-‐SR1+fix)


This is all that changed!!

OF (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.

new best practices and pitfalls for building products out of … · 2017. 12. 14. · best...

Documents