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 ¡

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 ¡ #ODSummit ¡

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

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 ¡ #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. #ODSummit ¡

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 ¡ Dave ¡Neary ¡on ¡Swimming ¡Upstream: ¡ hmp://www.slideshare.net/nearyd/swimming-­‑ #ODSummit ¡ upstream-­‑45666354 ¡

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

OpenDaylight ¡ Your ¡Proprietary ¡ Extension Example: Apps Code/Bundles ¡ Code/Bundles ¡ MyFabric ¡ App ¡ Flow ¡ Host ¡Tracking ¡ Topology ¡ Programming ¡ … ¡ … ¡ … ¡ … ¡ … ¡ … ¡ #ODSummit ¡

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

Extension Example: Modifying an Existing Service • Augment ¡exis5ng ¡ YANG ¡models ¡with ¡ OtherFabric ¡ new ¡informa5on ¡ App ¡ • Provide ¡Java ¡code ¡ to ¡extend ¡behavior ¡ OFVendorExt ¡ • Requires ¡Java ¡ YANG ¡ Flow ¡ extension ¡points ¡ Host ¡Tracking ¡ Topology ¡ Programming ¡ OFVendorExt ¡ Java ¡ • This ¡is ¡possible, ¡but ¡ complex, ¡needs ¡ thought ¡and ¡work ¡ … ¡ … ¡ … ¡ … ¡ Slides ¡from ¡ONS ¡talk: ¡ hmp://colindixon.com/wp-­‑content/uploads/2014/05/ #ODSummit ¡ 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! Ex: ¡Mul5ple ¡ Proprietary ¡ Releases ¡ T ¡= ¡0 ¡ T ¡= ¡1 ¡ T ¡= ¡2 ¡ T ¡= ¡3 ¡ T ¡= ¡4 ¡ Your ¡Company’s ¡Ar5facts ¡ C-­‑3 ¡ C-­‑1 ¡ C-­‑2 ¡ C-­‑4 ¡ C-­‑5 ¡ Released ¡OpenDaylight ¡ He ¡ He-­‑1 ¡ He-­‑2 ¡ He-­‑3 ¡ He-­‑4 ¡ Ar5facts ¡(Stable) ¡ Ac5ve ¡OpenDaylight ¡ He-­‑1 ¡ He-­‑2 He-­‑3 ¡ He-­‑4 ¡ He-­‑5 ¡ Development ¡(Vola5le) ¡ Dev ¡ Dev ¡ Dev ¡ Dev ¡ Dev ¡ #ODSummit ¡