VOLTHA releasing process documentation
Change-Id: I695567782e7abf41c122d43c9618f3340cb43dd5
diff --git a/overview/release_process.rst b/overview/release_process.rst
new file mode 100644
index 0000000..98807f7
--- /dev/null
+++ b/overview/release_process.rst
@@ -0,0 +1,219 @@
+======================
+VOLTHA Release process
+======================
+This document describes the technical steps of VOLTHA's release process.
+The document assumes you are creating a release named voltha-X.Y, where X is the major release versio
+and the y is the minor.
+See versioning in the :doc:`releases documentation </overview/releases>`
+
+Code Freeze and pre-release testing
+-----------------------------------
+
+VOLTHA is released every 6 months. The suggested codefreeze is 3 weeks before release.
+Code freeze means that no functionality is added, only bug fixes and tests can be added during the code freeze time.
+Code freeze is announced during the TST meetings and enforced by the core contributors that have +2/merge access.
+The 3 weeks of code freeze are used to stabilize the tests and prepare the components for the release.
+
+During code freeze the jenkins jobs test the latest code in master which, given the code freeze state, is the
+release candidate (RC) for the release.
+A release can be considered ready if the tests on Jenkins pass with no issue, both on hardware and bbsim jobs.
+
+Component releasing and Lazy Branching
+--------------------------------------
+In VOLTHA for a release we release components (services) and lazy branch when/if needed.
+Once a component (service) is ready to be released we increase the version in the VERSION file,
+going from the -dev or released version x.y.z to either a higher number in minor version (y) or in bug version (z).
+
+To allow for future patches to go into the repo in a way that does not conflict with the patch version,
+each component repo's VERSION file should have it's minor version increased in master. (ex: 1.1.X to 1.2.0-dev,
+so future 1.1.X+1 component release can easily be created for the released VOLTHA version).
+
+The same should be done on Helm charts in the chart repos post release,but the versions there shouldn't include a
+-dev suffix because chart publishing requires that every new chart version be unique and using un-suffixed SemVer is a
+better release numbering pattern.
+
+If a repository is branched the `.gitreview` file needs to be changed, adding `defaultorigin=voltha-X.Y` at the end.
+
+.. note::
+ Given the dependency of the containers on the protos and the library, if the voltha-protos and/or voltha-lib-go or
+ omci-lib-go need to be released, it should be done first and then updated in the components:
+
+ - release `voltha-proto`
+ - update `voltha-lib-go` and release it
+ - change the protos and lib-go versions in the components (in `go.mod`)
+ - issue `make mod-update`
+ - release the component
+
+
+Every repository that need releasing is listed here.
+
+Services:
+
+- `VOLTHA Core <https://github.com/opencord/voltha-go>`_
+- `OpenFlow Agent <https://github.com/opencord/ofagent-go>`_
+- `Openonu Adapter <https://github.com/opencord/voltha-openonu-adapter-go>`_
+- `Openolt Adapter <https://github.com/opencord/voltha-openolt-adapter>`_
+- `Openolt Agent <https://github.com/opencord/openolt>`_
+- `ONOS controller <https://github.com/opencord/voltha-onos>`_ (Note, only do it after releasing all the apps below)
+- `BBSIM <https://github.com/opencord/bbsim>`_
+- `BBSIM Sadis Server <https://github.com/opencord/bbsim-sadis-server>`_
+
+Libraries and APIs:
+
+- `VOLTHA protos <https://github.com/opencord/voltha-protos>`_
+- `VOLTHA Library in Go <https://github.com/opencord/voltha-lib-go>`_
+- `OMCI Library in GO <https://github.com/opencord/omci-lib-go>`_
+
+Tools:
+
+- `voltctl <https://github.com/opencord/voltctl>`_
+
+Configuration:
+
+- `pod-configs <https://github.com/opencord/pod-configs>`_
+
+ONOS Apps
+^^^^^^^^^
+
+The ONOS Apps need to be released in a different manner.
+
+There is a Jenkins job to release ONOS app: https://jenkins.opencord.org/job/onos-app-release.
+It requires to be triggered with specific parameters, as an example you can check the latest job in that pipeline.
+
+1. Build with parameters: use the name of the repo (not of the app itself)
+2. Wait for build to complete
+3. Merge the patches on gerrit https://gerrit.opencord.org/q/owner:do-not-reply%2540opennetworking.org
+4. It will trigger a publish job (https://jenkins.opencord.org/job/maven-publish_sadis/) that publish the artifact in
+ the staging repo on `sonatype <https://oss.sonatype.org>`_, you need to release it:
+ * Login on sonatype (for username and password contact michelle@opennetworking.org)
+ * search for org.opencord
+ * Select the app you want to release and click "all versions"
+ * Click on "Staging repositories" (in the left side navigation)
+ * In the top right search for last part of the app name (eg: olt)
+ * Click release (top left bar, small button)
+5. Wait until artefacts are published https://search.maven.org/search?q=g:org.opencord
+6. Go in other apps, update the dependency of released from x.y.z-SNAPSHOT to x.y.z
+7. Start over with new app
+
+.. note::
+ Given their inter dependency the ONOS apps need to be released in order:
+
+ 1. sadis
+ 2. olt, aaa, dhcpl2relay, mcast, igmpproxy, maclearning
+ 3. bng, PPPoE
+ 4. kafka
+
+ONOS APPs:
+
+- `AAA <https://github.com/opencord/aaa>`_
+- `BNG <https://github.com/opencord/bng>`_
+- `DHCP L2 Relay <https://github.com/opencord/dhcpl2relay>`_
+- `IGMPProxy <https://github.com/opencord/igmpproxy>`_
+- `Kafka <https://github.com/opencord/kafka-onos>`_
+- `Mac Learning <https://github.com/opencord/mac-learning>`_
+- `Multicast <https://github.com/opencord/mcast>`_
+- `OLT <https://github.com/opencord/olt>`_
+- `OLT Topology <https://github.com/opencord/olttopology>`_
+- `PPPoE Agent <https://github.com/opencord/pppoeagent>`_
+- `Sadis <https://github.com/opencord/sadis>`_
+
+
+
+
+Creating the release
+--------------------
+
+Once the components have been tested and the release is considered ready there are 3 more elements that need to be
+tagged:
+
+- `VOLTHA Helm Charts <https://github.com/opencord/voltha-helm-charts>`_
+- `VOLTHA System Tests <https://github.com/opencord/voltha-system-tests>`_
+- `VOLTHA docs <https://github.com/opencord/voltha-docs>`_
+
+These 3 repos are the only ones that receive a X.Y.Z tag. Other repos that contain individual
+components have their own versioning/release cadence, driven by SemVer.
+
+Helm Charts
+^^^^^^^^^^^
+
+The official action of creating the voltha-X.Y release is releasing the voltha helm chart, and adapter charts
+with version:X.Y.Z (e.g. 2.10.0) specified in Chart.yaml within the voltha-helm-charts repo, and within the VERSION
+file in that repo.
+A branch named voltha-X.Y needs to be created on the voltha-helm-charts repo.
+The helm charts repo overall VERSION should also be incremented to the next minor version (X.Y+1-dev), so all X.Y.Z
+releases of the overall charts repo will happen on the voltha-X.Y branch.
+
+Voltha-system-tests
+^^^^^^^^^^^^^^^^^^^
+Accompanying tests for voltha-X.Y are created by creating a branch created named voltha-X.Y on the voltha-system-tests
+repo and creating a tag X.Y.Z on that branch.
+
+Documentation and Release Notes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Release notes for the voltha-X.Y release are created and added to the voltha-docs repo. Please follow the template of
+past releases, an :doc:`example </voltha_releases/voltha_2.9>`
+
+Also, if needed a voltha-X.Y branch is created on docs repo. These release notes also contain all the
+versions of components that will be released, and may be updated during the final QA process.
+At release we create a tag X.Y.Z in the VERSION file.
+
+CI-Management
+^^^^^^^^^^^^^
+In the `Ci management <https://github.com/opencord/ci-management>`_ repository create the /voltha-x.y.z folder and copy the /master repos
+Testing CI jobs should be created that check out the voltha-X.Y branch of the voltha-system-tests repo, testing the
+charts as checked out with the voltha-X.Y tag of voltha-helm-charts.
+
+
+Release support and bug-fixing
+------------------------------
+
+What changes can be brought into the X.Y.Z branch?
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Has to be a bug or non-code fix.
+
+Add a Jira item with type Bug, tag against VOLTHA vX.Y
+Discuss on the Voltha mailing list, or in all-Voltha meeting, get consensus on whether should be brought to X.Y.z
+Documentation or other non-code updates are also acceptable
+
+What is a bug? Not a new feature!
+Anything that causes a functional regression test (Robot tests) to fail
+Severe issue (causes data loss or crash), or frequently occurring -> add to X.Y
+Issues that are merely annoying and don't cause data loss or a crash, or are very infrequently occurring -> may
+wait for next release
+
+WHen a bug is found please add to tests both on the released version and the master branch, if tests don't cover
+the bug. Add to Robot tests for integration-related issues, to Unit tests for code-level or functional issues.
+
+Update/Fixes to the released version
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+This section shows how to create minor releases on the X.Y.Z branch when a bug fix is required.
+
+If a fix is needed to the helm charts:
+
+- Make the fix on the master branch of voltha-helm-charts (assuming that it is required in both places).
+- After the master tests pass, manually cherry-pick the fix to the voltha-X.Y branch (the Chart version would be
+ different, requiring the manual step).
+- Cherry-picked patchsets on that branch will be checked by the voltha-X.Y branch of tests.
+- When it passes, submitting the change will make a new X.Y.Z release
+- Update the documentation to reflect the chart changes, a description of the changes made, and increment the tag
+ on the docs from X.Y.Z to X.Y.Z+1, to reflect the patch change.
+- If all the charts are updated and working correctly, create a new charts point release by increasing the
+ X.Y.Z VERSION file in the voltha-helm-charts repo. The versions need to be updated in the voltha-docs repo,
+ which needs to be tagged as well, thus releasing it.
+
+If a fix is needed to the components/containers that are included by the helm charts:
+
+- Develop a fix to the issue on the master branch, get it approved after passing master tests.
+- Manually cherry-pick to the voltha-X.Y branch of the component (create one fi needed)
+- incrementing the patch version in the VERSION file,
+- test with the voltha-X.Y version of voltha-system-tests and helm charts.
+- Update helm charts and go through the helm chart update process above.
+- Update the voltha-docs with the right version of the component.
+
+If a fix is needed to the ONOS apps:
+
+- Create a branch here https://gerrit.opencord.org/plugins/gitiles/olt/+/refs/heads/olt-4.1
+- then `Git checkout -b <branch-name> opencord/<version>`
+- Then push a commit changing to `.1-SNAPSHOT` more (see e.g. https://gerrit.opencord.org/c/igmpproxy/+/19589)
+- Then push you changes (e.g. https://gerrit.opencord.org/c/igmpproxy/+/19590)
+- Then release as per the process above.
diff --git a/overview/workflows.html b/overview/workflows.html
new file mode 100644
index 0000000..7a3ad04
--- /dev/null
+++ b/overview/workflows.html
@@ -0,0 +1,496 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+<meta name="generator" content="Docutils 0.16: http://docutils.sourceforge.net/" />
+<title>Operator workflows</title>
+<style type="text/css">
+
+/*
+:Author: David Goodger (goodger@python.org)
+:Id: $Id: html4css1.css 7952 2016-07-26 18:15:59Z milde $
+:Copyright: This stylesheet has been placed in the public domain.
+
+Default cascading style sheet for the HTML output of Docutils.
+
+See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
+customize this style sheet.
+*/
+
+/* used to remove borders from tables and images */
+.borderless, table.borderless td, table.borderless th {
+ border: 0 }
+
+table.borderless td, table.borderless th {
+ /* Override padding for "table.docutils td" with "! important".
+ The right padding separates the table cells. */
+ padding: 0 0.5em 0 0 ! important }
+
+.first {
+ /* Override more specific margin styles with "! important". */
+ margin-top: 0 ! important }
+
+.last, .with-subtitle {
+ margin-bottom: 0 ! important }
+
+.hidden {
+ display: none }
+
+.subscript {
+ vertical-align: sub;
+ font-size: smaller }
+
+.superscript {
+ vertical-align: super;
+ font-size: smaller }
+
+a.toc-backref {
+ text-decoration: none ;
+ color: black }
+
+blockquote.epigraph {
+ margin: 2em 5em ; }
+
+dl.docutils dd {
+ margin-bottom: 0.5em }
+
+object[type="image/svg+xml"], object[type="application/x-shockwave-flash"] {
+ overflow: hidden;
+}
+
+/* Uncomment (and remove this text!) to get bold-faced definition list terms
+dl.docutils dt {
+ font-weight: bold }
+*/
+
+div.abstract {
+ margin: 2em 5em }
+
+div.abstract p.topic-title {
+ font-weight: bold ;
+ text-align: center }
+
+div.admonition, div.attention, div.caution, div.danger, div.error,
+div.hint, div.important, div.note, div.tip, div.warning {
+ margin: 2em ;
+ border: medium outset ;
+ padding: 1em }
+
+div.admonition p.admonition-title, div.hint p.admonition-title,
+div.important p.admonition-title, div.note p.admonition-title,
+div.tip p.admonition-title {
+ font-weight: bold ;
+ font-family: sans-serif }
+
+div.attention p.admonition-title, div.caution p.admonition-title,
+div.danger p.admonition-title, div.error p.admonition-title,
+div.warning p.admonition-title, .code .error {
+ color: red ;
+ font-weight: bold ;
+ font-family: sans-serif }
+
+/* Uncomment (and remove this text!) to get reduced vertical space in
+ compound paragraphs.
+div.compound .compound-first, div.compound .compound-middle {
+ margin-bottom: 0.5em }
+
+div.compound .compound-last, div.compound .compound-middle {
+ margin-top: 0.5em }
+*/
+
+div.dedication {
+ margin: 2em 5em ;
+ text-align: center ;
+ font-style: italic }
+
+div.dedication p.topic-title {
+ font-weight: bold ;
+ font-style: normal }
+
+div.figure {
+ margin-left: 2em ;
+ margin-right: 2em }
+
+div.footer, div.header {
+ clear: both;
+ font-size: smaller }
+
+div.line-block {
+ display: block ;
+ margin-top: 1em ;
+ margin-bottom: 1em }
+
+div.line-block div.line-block {
+ margin-top: 0 ;
+ margin-bottom: 0 ;
+ margin-left: 1.5em }
+
+div.sidebar {
+ margin: 0 0 0.5em 1em ;
+ border: medium outset ;
+ padding: 1em ;
+ background-color: #ffffee ;
+ width: 40% ;
+ float: right ;
+ clear: right }
+
+div.sidebar p.rubric {
+ font-family: sans-serif ;
+ font-size: medium }
+
+div.system-messages {
+ margin: 5em }
+
+div.system-messages h1 {
+ color: red }
+
+div.system-message {
+ border: medium outset ;
+ padding: 1em }
+
+div.system-message p.system-message-title {
+ color: red ;
+ font-weight: bold }
+
+div.topic {
+ margin: 2em }
+
+h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
+h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
+ margin-top: 0.4em }
+
+h1.title {
+ text-align: center }
+
+h2.subtitle {
+ text-align: center }
+
+hr.docutils {
+ width: 75% }
+
+img.align-left, .figure.align-left, object.align-left, table.align-left {
+ clear: left ;
+ float: left ;
+ margin-right: 1em }
+
+img.align-right, .figure.align-right, object.align-right, table.align-right {
+ clear: right ;
+ float: right ;
+ margin-left: 1em }
+
+img.align-center, .figure.align-center, object.align-center {
+ display: block;
+ margin-left: auto;
+ margin-right: auto;
+}
+
+table.align-center {
+ margin-left: auto;
+ margin-right: auto;
+}
+
+.align-left {
+ text-align: left }
+
+.align-center {
+ clear: both ;
+ text-align: center }
+
+.align-right {
+ text-align: right }
+
+/* reset inner alignment in figures */
+div.align-right {
+ text-align: inherit }
+
+/* div.align-center * { */
+/* text-align: left } */
+
+.align-top {
+ vertical-align: top }
+
+.align-middle {
+ vertical-align: middle }
+
+.align-bottom {
+ vertical-align: bottom }
+
+ol.simple, ul.simple {
+ margin-bottom: 1em }
+
+ol.arabic {
+ list-style: decimal }
+
+ol.loweralpha {
+ list-style: lower-alpha }
+
+ol.upperalpha {
+ list-style: upper-alpha }
+
+ol.lowerroman {
+ list-style: lower-roman }
+
+ol.upperroman {
+ list-style: upper-roman }
+
+p.attribution {
+ text-align: right ;
+ margin-left: 50% }
+
+p.caption {
+ font-style: italic }
+
+p.credits {
+ font-style: italic ;
+ font-size: smaller }
+
+p.label {
+ white-space: nowrap }
+
+p.rubric {
+ font-weight: bold ;
+ font-size: larger ;
+ color: maroon ;
+ text-align: center }
+
+p.sidebar-title {
+ font-family: sans-serif ;
+ font-weight: bold ;
+ font-size: larger }
+
+p.sidebar-subtitle {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+p.topic-title {
+ font-weight: bold }
+
+pre.address {
+ margin-bottom: 0 ;
+ margin-top: 0 ;
+ font: inherit }
+
+pre.literal-block, pre.doctest-block, pre.math, pre.code {
+ margin-left: 2em ;
+ margin-right: 2em }
+
+pre.code .ln { color: grey; } /* line numbers */
+pre.code, code { background-color: #eeeeee }
+pre.code .comment, code .comment { color: #5C6576 }
+pre.code .keyword, code .keyword { color: #3B0D06; font-weight: bold }
+pre.code .literal.string, code .literal.string { color: #0C5404 }
+pre.code .name.builtin, code .name.builtin { color: #352B84 }
+pre.code .deleted, code .deleted { background-color: #DEB0A1}
+pre.code .inserted, code .inserted { background-color: #A3D289}
+
+span.classifier {
+ font-family: sans-serif ;
+ font-style: oblique }
+
+span.classifier-delimiter {
+ font-family: sans-serif ;
+ font-weight: bold }
+
+span.interpreted {
+ font-family: sans-serif }
+
+span.option {
+ white-space: nowrap }
+
+span.pre {
+ white-space: pre }
+
+span.problematic {
+ color: red }
+
+span.section-subtitle {
+ /* font-size relative to parent (h1..h6 element) */
+ font-size: 80% }
+
+table.citation {
+ border-left: solid 1px gray;
+ margin-left: 1px }
+
+table.docinfo {
+ margin: 2em 4em }
+
+table.docutils {
+ margin-top: 0.5em ;
+ margin-bottom: 0.5em }
+
+table.footnote {
+ border-left: solid 1px black;
+ margin-left: 1px }
+
+table.docutils td, table.docutils th,
+table.docinfo td, table.docinfo th {
+ padding-left: 0.5em ;
+ padding-right: 0.5em ;
+ vertical-align: top }
+
+table.docutils th.field-name, table.docinfo th.docinfo-name {
+ font-weight: bold ;
+ text-align: left ;
+ white-space: nowrap ;
+ padding-left: 0 }
+
+/* "booktabs" style (no vertical lines) */
+table.docutils.booktabs {
+ border: 0px;
+ border-top: 2px solid;
+ border-bottom: 2px solid;
+ border-collapse: collapse;
+}
+table.docutils.booktabs * {
+ border: 0px;
+}
+table.docutils.booktabs th {
+ border-bottom: thin solid;
+ text-align: left;
+}
+
+h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
+h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
+ font-size: 100% }
+
+ul.auto-toc {
+ list-style-type: none }
+
+</style>
+</head>
+<body>
+<div class="document" id="operator-workflows">
+<span id="workflows"></span>
+<h1 class="title">Operator workflows</h1>
+
+<p><tt class="docutils literal">Workflow</tt> is a term that spilled from the SEBA Reference Design (RD) into VOLTHA.</p>
+<p>In SEBA a workflow is a collection of subscriber management items like identification, location,
+and bandwidth profile. In addition each workflows maps to a service type which translates to a technology profile,
+and an operator desired flow of operations (i.e state-machine).
+The workflow is implemented by a selection of ONOS apps, XOS services (in SEBA)
+and a set of configurations (sadis, etcd, netcfg). Those apps paired with the configuration specified by the
+workflow (e.g. need EAPOL) in turn create low level flows, groups, meters, schedulers, queues etc.
+A workflow is then triggered by a particular set of APIs, for example the request to add a subscriber.</p>
+<p>A full description of the different operator's workflows can be
+<a class="reference external" href="https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF">found here</a>.</p>
+<p>A big part of the workflow in SEBA is defined within NEM (Network Edge Mediator).
+Given that NEM is not available in a plain VOLTHA deployment the user has to ensure proper config in the right places,
+and then triggering of api's themselves.</p>
+<p>To deploy a specific workflow follow the steps under <cite>deploying-a-different-workflow</cite> in the <a class="reference external" href="../voltha-helm-charts/README.md">voltha-helm-charts
+README</a>.</p>
+<p>A workflow in VOLTHA entails different elements: Customer tag allocation, Technology profile, Bandwidth profile,
+Flow and Group Management</p>
+<div class="section" id="customer-tag-allocation">
+<h1>Customer tag allocation</h1>
+<p>The vlan tags for a particular subscriber are defined in the <tt class="docutils literal">sadis</tt> configuration.
+<a class="reference external" href="https://github.com/opencord/sadis">Sadis</a> stands for <cite>Subscriber and Device Information Service</cite>
+and is the ONOS application responsible to store and distribute Subscriber information.</p>
+<p>Information on different <tt class="docutils literal">sadis</tt> configurations can be found here:
+<a class="reference external" href="https://docs.google.com/document/d/1JLQ51CZg4jsXsBQcrJn-fc2kVvXH6lw0PYoyIclwmBs">https://docs.google.com/document/d/1JLQ51CZg4jsXsBQcrJn-fc2kVvXH6lw0PYoyIclwmBs</a></p>
+</div>
+<div class="section" id="technology-profile">
+<h1>Technology profile</h1>
+<p>Technology profiles describes technology specific attributes required to implement
+Subscriber Services on an OpenFlow managed Logical Switch overlaid upon an OLT
+or other technology specific platform.</p>
+<p>More information on Technology profiles can be found here:
+<a class="reference external" href="https://youtu.be/L0JBJ3R1Mag">2018/03/22 VOLTHA TST on Technology profile</a>
+<a class="reference external" href="https://wiki-archive.opencord.org/attachments/4981667/4981671.docx">VOLTHA technical notes on Technology profile</a>
+<a class="reference external" href="https://wiki-archive.opencord.org/attachments/4981667/4981670.docx">VOLTHA Implementation of Technology profiles</a>
+<a class="reference external" href="https://wiki-archive.opencord.org/Technology-Profile-Instance_4982088.html">Technology profile instance example</a></p>
+<p>Technology profiles in VOLTHA are stored in ETCD. If you want to load a custom
+Technology profile in your stack you can do so by:</p>
+<pre class="code bash literal-block">
+<span class="name variable">ETCD_POD</span><span class="operator">=</span><span class="keyword">$(</span>kubectl get pods <span class="punctuation">|</span> grep etcd <span class="punctuation">|</span> awk <span class="literal string single">'NR==1{print \$1}'</span><span class="keyword">)</span>
+kubectl cp <my-tech-profile>.json <span class="name variable">$ETCD_POD</span>:/tmp/tp.json
+kubectl <span class="name builtin">exec</span> -it <span class="name variable">$ETCD_POD</span> -- /bin/sh -c <span class="literal string single">'cat /tmp/tp.json | ETCDCTL_API=3 etcdctl put service/voltha/technology_profiles/XGS-PON/64'</span>
+</pre>
+<p><em>Note that `XGS-PON` represents the technology of your OLT device and `64` is
+the default id of the technology profile. If you want to use a technology profile
+that is not the default for a particular subscriber that needs to be configured
+in `sadis`.</em></p>
+</div>
+<div class="section" id="bandwidth-profile">
+<h1>Bandwidth profile</h1>
+<p>Bandwidth profiles control the allocation Bandwidth for a particular subscriber.
+They are defined in the <cite>sadis</cite> application.
+VOLTHA supports both the MEF and IETF definition of Bandwidth Profile.
+More information on the different definitions can be found on the <a class="reference external" href="https://wiki.mef.net/display/CESG/Bandwidth+Profile">MEF wiki</a>.</p>
+<p>MEF:</p>
+<pre class="code json literal-block">
+<span class="punctuation">{</span><span class="whitespace">
+ </span><span class="name tag">"id"</span><span class="whitespace"> </span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal string double">"Default"</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"cir"</span><span class="whitespace"> </span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">1000000</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"cbs"</span><span class="whitespace"> </span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">1001</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"eir"</span><span class="whitespace"> </span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">1002</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"ebs"</span><span class="whitespace"> </span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">1003</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"air"</span><span class="whitespace"> </span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">1004</span><span class="whitespace">
+</span><span class="punctuation">}</span>
+</pre>
+<p>IETF:</p>
+<pre class="code json literal-block">
+<span class="punctuation">{</span><span class="whitespace">
+ </span><span class="name tag">"id"</span><span class="whitespace"> </span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal string double">"Default"</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"pir"</span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">1168192</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"pbs"</span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">0</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"cir"</span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">0</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"cbs"</span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">0</span><span class="punctuation">,</span><span class="whitespace">
+ </span><span class="name tag">"gir"</span><span class="punctuation">:</span><span class="whitespace"> </span><span class="literal number integer">0</span><span class="whitespace">
+</span><span class="punctuation">}</span>
+</pre>
+<p>Each bandwidth profile is then translated into an OpenFlow Meter for configuration on the OLT.</p>
+<p>Each OpenFlow Meter is then translated to a different TCONT type in the <cite>openolt-adapter</cite>.
+VOLTHA supports all 5 TCONT types.</p>
+<p>The translation of Bandwidth profile parameters to TCONT types happens as follows:</p>
+<ul>
+<li><div class="first line-block">
+<div class="line"><cite>Type-1</cite>: If CIR > 0, CIR = PIR, additional_bw_eligibility = none --> set guaranteed_bw = maximum_bw = CBR_RT_BW</div>
+<div class="line">(or CBR_NRT_BW) = CIR and alloc_type=none. (alloc_type is inferred from the other parameters)</div>
+</div>
+</li>
+<li><div class="first line-block">
+<div class="line"><cite>Type-2</cite>: If CIR = 0, GIR or AIR > 0, GIR or AIR = PIR, additional_bw_eligibility = none --> set guaranteed_bw =</div>
+<div class="line">maximum_bw = AIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR (alloc_type is set to NSR by default)</div>
+</div>
+</li>
+<li><div class="first line-block">
+<div class="line"><cite>Type-3</cite>: If CIR = 0, GIR or AIR > 0, PIR > GIR or AIR, additional_bw_eligibility = non_assured --></div>
+<div class="line">guaranteed_bw = AIR, maximum_bw = PIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR and send</div>
+<div class="line">these parameters to BAL. (alloc_type is set to NSR by default)</div>
+</div>
+</li>
+<li><div class="first line-block">
+<div class="line"><cite>Type-4</cite>: if CIR = 0, GIR or AIR = 0, PIR > 0, additional_bw_eligibility = best_effort --> set</div>
+<div class="line">guaranteed_bw = 0, maximum_bw = PIR, CBR_RT_BW = 0 and CBR_NRT_BW = 0 and alloc_type = NSR and send</div>
+<div class="line">(alloc_type is set to NSR by default)</div>
+</div>
+</li>
+<li><div class="first line-block">
+<div class="line"><cite>Type-5</cite>: if CIR > 0, PIR >= CIR + GIR or AIR, additional_bw_eligibility = non_assured or</div>
+<div class="line">best_effort --> set guaranteed_bw = CIR+AIR, maximum_bw = PIR, CBR_RT_BW = 0 (or CBR_NRT_BW) = CIR</div>
+<div class="line">and alloc_type = NSR. (alloc_type is set to NSR by default)</div>
+</div>
+</li>
+</ul>
+<p>Further implementation details can be found in <a class="reference external" href="https://docs.google.com/document/d/1HipmsHD5LEQlOc-Y2tYV7DHD1fn7-_1lehBgp79sRwU/edit#">this document</a>.</p>
+</div>
+<div class="section" id="flow-management">
+<h1>Flow management</h1>
+<p>Flows are managed in ONOS by the <cite>olt</cite> application. Through the configuration of
+this application you can define whether your setup will create:</p>
+<ul class="simple">
+<li>An <cite>EAPOL</cite> trap flow</li>
+<li>A <cite>DHCP</cite> trap flow</li>
+<li>An <cite>IGMP</cite> trap flow</li>
+</ul>
+<p>in addition to the default data plane flows.</p>
+</div>
+<div class="section" id="group-management">
+<h1>Group management</h1>
+<p>Groups are managed in ONOS by the <cite>mcast</cite> application. Through the configuration of
+this application you can achieve multicast for services such as IpTV.</p>
+</div>
+</div>
+</body>
+</html>