Best Practices and Pitfalls for Building Products out of - - PowerPoint PPT Presentation

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 ¡
• wn ¡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-­‑2 Dev ¡ 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. ¡