manuals/developer-guide/src/main/asciidoc/core/developerkickstarterforodl.adoc

   1 == Kick-starter for OpenDaylight developers\r
   2 \r
   3 See updated developer getting started information at the https://wiki.opendaylight.org/view/GettingStarted:Developer_Main[Getting Started for Developers Page].\r
   4 \r
   5 === Downloading the OpenDaylight software\r
   6 \r
   7 You can either download the software using CLI or Eclipse. See the relevant sections in the OpenDaylight wiki.\r
   8 \r
   9 \r
  10 === OpenDaylight infrastructure\r
  11 \r
  12 \r
  13 NOTE: This section is for developers who wish to contribute to the OpenDaylight project. For developers who wish to build proprietary applications based on OpenDaylight, see the section on RESTCONF.\r
  14 \r
  15 The OpenDaylight infrastructure consists of the following components.\r
  16 \r
  17 * *Source code manager:* http://git-scm.com/[Git]. For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:Gerrit_Setup[Getting started with Git and Gerrit].\r
  18 \r
  19 * *Code review tool:* https://git.opendaylight.org/gerrit/[Gerrit]. For more information, see https://wiki.opendaylight.org/view/OpenDaylight_Controller:Gerrit_Setup[Getting started with Git and Gerrit].\r
  20 \r
  21 * *Continuous integration:* https://jenkins.opendaylight.org/[OpenDaylight Jenkins]. For more information, see Getting started with Jenkins.\r
  22 \r
  23 * *Artefact repository:* https://nexus.opendaylight.org/[OpenDaylight Nexus] For more information, see https://wiki.opendaylight.org/view/Infrastructure:Nexus[Getting started with Nexus].\r
  24 \r
  25 * *Quality Management:* https://sonar.opendaylight.org/[OpenDaylight Sonar]. \r
  26 \r
  27 * *Bug tracking:* http://bugs.opendaylight.org/[OpenDaylight Bugzilla]. \r
  28 \r
  29 * *Wiki:* https://wiki.opendaylight.org/[OpenDaylight wiki]. \r
  30 \r
  31 === Development workflow for contributing to the OpenDaylight project\r
  32 \r
  33 The steps below detail the development workflow for contributing to the OpenDaylight project, including any of its sub projects.\r
  34 \r
  35 \r
  36 . *Identifying the project:* Identify the project under OpenDaylight for which you are going to contribute code. For the list of available projects, see https://wiki.opendaylight.org/view/Main_Page#Projects[OpenDaylight Projects].\r
  37 \r
  38 [start=2]\r
  39 . *Locating the project repository:* Navigate to the selected project page and identify the repository for the project. It maybe listed in the main page or in one of the sub-pages.\r
  40 \r
  41 [start=4]\r
  42 . *Pulling the dependent artefacts:* Pull the dependent artefacts. Most Java and OSGI code bases have a large number of dependencies that are managed by maven. During build, the artefacts (usually binary jars) for those dependencies are pulled from a Development Nexus Artefact Repository.\r
  43 \r
  44 [start=3]\r
  45 . *Pulling the code:* Pull the code from the repository to your local system. For more information, see the relevant section about the project in this developer's guide.\r
  46 \r
  47 \r
  48 [start=5]\r
  49 . *Contributing to the code:* Start working on the code in your local system. If you think your contributions are ready for review by a group of peer collaborators, push the code to the repository.\r
  50 \r
  51 . *Triggering a Jenkins verification:* Trigger a Jenkins verification in Gerrit. Jenkins runs continuous integration tests.\r
  52 \r
  53 [start=8]\r
  54 . *Running CI and verifying the patch:* If the Jenkins tests are successful, the patch is verified in Gerrit.\r
  55 \r
  56 . *Reviewing the patch:* A committer picks the patch for consideration. The committer may have comments for you to fix in your code. In this case, make the code changes and re-submit the code for review.\r
  57 \r
  58 . *Submitting the patch:* If there are no more comments, the committer indicates to Gerrit that the patch is approved and verified.\r
  59 \r
  60 . *Merging the patch:* Gerrit merges the patch into the branch.\r
  61 \r
  62 . *Triggering a Jenkins verification:* Jenkins is triggered to run the continuous integration tests on the result of the merge.\r
  63 \r
  64 . *Running a Jenkins merge:* Jenkins kicks off the builds for the new artefacts that need to be in the Development Nexus Artifact Repository.\r
  65 \r
  66 . *Uploading new artefacts:* If builds (and possible other CI tasks) are successful, Jenkins uploads the new artefacts to the Development Nexus Artefact Repository.\r
  67 \r
  68 \r
  69 === OpenDaylight architectural principles\r
  70 \r
  71 \r
  72 * *Runtime Modularity and Extensibility*: Allow for a modular, extensible controller that supports installation, removal, and updates to service implementations within a running controller. The feature is also known as in service software upgrade (ISSU).\r
  73 \r
  74 * *Multiprotocol Southbound*: Allow for more than one protocol interface with network elements with diverse capabilities southbound from the controller.\r
  75 \r
  76 \r
  77 * *Service Abstraction Layer (SAL)*: Where possible, allow for multiple southbound protocols to present the same northbound service interfaces.\r
  78 \r
  79 \r
  80 * *Open Extensible Northbound API*: Allow for an extensible set of application-facing APIs both across runtimes using REST (level 3 API) and within the same runtime using function calls (level 2 API). The set of accessible functions must be the same.\r
  81 \r
  82 \r
  83 * *Support for Multitenancy/Slicing*: Allow for the network to be logically (and/or physically) split into different slices or tenants with parts of the controller and modules explicitly dedicated to one or a subset of these slices. This includes allowing the controller to present different views of the controller depending on which slice the caller is from.\r
  84 \r
  85 \r
  86 * *Consistent Clustering*: Clustering that gives fine-grained redundancy and scale-out while insuring network consistency.\r
  87 \r
  88 \r
  89 === Open extensible northbound API\r
  90 \r
  91 Allow for an extensible set of application-facing APIs both across runtimes using REST (level 3 API) and within the same runtime using function calls (level 2 API). The set of accessible functions must be the same.\r
  92 \r
  93 \r
  94 Here are the APIs presented by the OpenDaylight projects:\r
  95 \r
  96 * OpenDaylight Controller:\r
  97 ** AD-SAL https://wiki.opendaylight.org/view/OpenDaylight_Controller:REST_Reference_and_Authentication[REST and Java APIs]\r
  98 \r
  99 \r
 100 ** MD-SAL https://wiki.opendaylight.org/view/OpenDaylight_Controller:RESTCONF_Northbound_APIs[RESTCONF Northbound APIs]\r
 101 \r
 102 \r
 103 * OpenDaylight Virtual Tenant Network - https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Coordinator:RestApi[REST API]\r
 104 \r
 105 \r
 106 * Open DOVE - https://wiki.opendaylight.org/view/Open_DOVE:API[Northbound API]\r
 107 \r
 108 \r
 109 * OpenFlow Plugin - N/A\r
 110 \r
 111 \r
 112 * Affinity Metadata Service - N/A\r
 113 \r
 114 \r
 115 * YANG Tools - https://wiki.opendaylight.org/view/YANG_Tools:Available_Models[Available YANG models]\r
 116 \r
 117 \r
 118 * LISP Flow Mapping - https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Java_API[Java API] and https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:REST_API[REST API]\r
 119 \r
 120 \r
 121 * OVSDB - https://wiki.opendaylight.org/view/OVSDB_Integration:REST_API[REST API]\r
 122 \r
 123 \r
 124 * OpenFlow Protocol Library - https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Main#Public_API[public API]\r
 125 \r
 126 \r
 127 * BGP-LS/PCEP - N/A\r
 128 \r
 129 \r
 130 * Defense4All - N/A\r
 131 \r
 132 \r
 133 * SNMP4SDN - https://wiki.opendaylight.org/view/File:SAL_API_for_SNMP_SouthBound_Plugin.pdf[(proposed) API]\r
 134 \r