DEPRECATED

VOLTHA 2.7 was the last release that officially supported kind-voltha as a deployment tool. From now on the deployment is driven via helm charts, please refer to voltha-helm-charts and voltha-docs for more information. This codebase is going to be removed after the VOLTHA 2.8 release LTS support ends in December 2022.

VOLTHA DEPLOYMENT TOOL

Thie repository describes how to the the voltha script to install a VOLTHA deployment. voltha can be used to deploy an instance into an existing Kubernetes cluster (physical or virtual) or can be start up a local docker-in-docker KinD Kuberentes cluster in which to deploy VOLTHA.

When deploying VOLTHA there are several configuration options tha can be set as described in the CONFIGURATION section below. All configuration options are specified as envirment variables.

PREREQUISITES

The voltha script uses several standard Linux tools to deploy VOLTHA including curl, sed, and jq. This tools must be installed before using the script. The script checks for the presence of these tools before it deployes VOLTHA and will exit with an error if the tools are not present.

NOTE: If you are deploying a KinD Kubernetes cluster using the voltha script, you must also also have Docker installed

NAMING YOUR CLUSTER

The voltha script can be used to manage multiple clusters at the same time, thus it's important to always name your cluster.

export NAME=minimal

Throughout this README.md file you'll find multiple references to $NAME and that can always be replaced with the name your cluster (the default value is local).

TL;DR

OK, if you really don't care how it starts and you just want it started. After cloning the repository and making sure you have the prerequisites installed, just execute

DEPLOY_K8S=y WITH_BBSIM=y WITH_RADIUS=y CONFIG_SADIS=y ./voltha up

and the minimal cluster should start.

To remove voltha use DEPLOY_K8S=y ./voltha down

RUN WITHOUT CLONING REPOSITORY

The voltha script can be run without cloning the complete repository. To do so, download the script and run it.

curl -sSL https://raw.githubusercontent.com/opencord/kind-voltha/master/voltha --output ./voltha
chmod +x ./voltha
DEPLOY_K8S=y WITH_BBSIM=y WITH_RADIUS=y CONFIG_SADIS=y ./voltha up

NOTE: Shown significantly sped up (20x), actual install was about 8 minutes.

CONFIGURATION

The option should be set using environment variables, thus to start VOLTHA with the BBSIM POD, RADIUS, EFK and ONOS SADIS configured you could use the following command:

WITH_BBSIM=yes WITH_RADIUS=y WITH_EFK=y CONFIG_SADIS=y  voltha up

To start a specific version of VOLTHA, e.g. 2.5, you could use the following commands:

source releases/voltha-2.5 && voltha up

Please check the releases folder to see the available ones and pick the correct tag associatet do that release.

Managing the cluster(s) size

The voltha script supports configuration for cluster of different sizes. For example you can setup an HA cluster with:

NUM_OF_WORKER_NODES=3 NUM_OF_ONOS=3 NUM_OF_KAFKA=3 NUM_OF_ETCD=3 NUM_OF_ATOMIX=3 ./voltha up

As usual one can add as many other options, for example CONFIG_SADIS=y.

Custom Namespaces

Separate namespaces can be specified for various components

• VOLTHA_NS (default: voltha) for cores, ofagent, Etcd (yes), Kafka (yes)
• ADAPTER_NS (default: voltha) for device adapters
• INFRA_NS (default: default) for RADIUS, ONOS, Etcd (external), Kafka (external)
• BBSIM_NS (default: voltha) for BBSIM instances

As an example BBSIM_NS=devices deployes BBSim in the devices namespace.

External Kafka, Etcd and ONOS

WITH_ETCD, WITH_KAFKA and WITH_ONOS can have different values depending on the deployment needs:

When specifying the <endpoint> of the service the format for each of these is service-name[:port]. Port is optional and will default to the standard port for the given service. For example, WITH_KAFA=kafka.infra.svc.cluster.local

Specifying the endpoint enable to use ./voltha up incrementally, for example:

DEPLOY_K8S=n WITH_BBSIM=y WITH_RADIUS=no CONFIG_SADIS=no  WITH_ONOS=onos-openflow.infra.svc.cluster.local  WITH_ETCD=etcd-cluster-client.infra.svc.cluster.local WITH_KAFKA=kafka.infra.svc.cluster.local  INFRA_NS=infra BBSIM_NS=devices ADAPTER_NS=adapters ./voltha up

starts VOLTHA with external ONOS,KAFKA,ETCD in the infra namespace.

CONFIG_SADIS Values

BBSIM_CFG Values

BBSIM_CFG contains a description of the services that is needed to properly configure BBSim. Examples are available in the configs folder. It can be pointed to any valid BBSim service configuration.

You'll note that the examples contain a :TAG: placeholder. That is used by kind-voltha to generate different C/S_TAG combinations when deploying multiple instances of BBSim and it's replaced with an incremental number starting from 900.

EFK Configuration for accessing Voltha component logs

If EFK is selected for deployment with VOLTHA, WITH_EFK=yes, then a single node elasticsearch and kibana instance will be deployed and a fluentd-elasticsearch pod will be deployed on each node that allows workloads to be scheduled.

Additionally a port-forward will be established so that you can access elasticsearch(9200) and kibana(5601) from outside the Kubernetes cluster. To access the kibana web interface user the URL http://localhost:5601.

NOTE: By default the security and physical persistance(disk) features are not enabled for elasticsearch and kibana. The security features can be enabled via X-Pack plugin and Role Based Access Control (RBAC) in Elasticsearch by adding the required settings in yaml file. To enable security features reference the following links: EFK-Setup-With-Kind-Voltha elasticsearch kibana

When running an EFK stack in production there are several maintenance that need to be periodically performed including indexes triming. When planning to deploy an EFK stack to production you should fully understand the recommendations as described in the product documenation: https://www.elastic.co/guide/index.html

Jaeger Tracing Stack for analyzing Voltha Component Traces

If Tracing is selected for deployment with VOLTHA using WITH_TRACING=yes option, then a single Jaeger all-in-one instance will be deployed using Memory as Storage backend for traces sent by Voltha conatiners.

Additionally a port-forward will be established so that you can access Jaeger GUI(16686) from outside the Kubernetes cluster using URL http://localhost:16686.

Controlling VOLTHA with an ONOS cluster

To provide HA, resilinecy and failover ONOS can be configured in cluster mode. A 3 node ONOS deployment for example can be achieved via:

NUM_OF_WORKER_NODES=3 WITH_ONOS=classic NUM_OF_ONOS=3 NUM_OF_ATOMIX=3 ./voltha up

Please note the above command deploys a 3 worker nodes for k8s and WITH_ONOS=classic that uses the cluster-enabled helm chart for ONOS (version 2.2). The NUM_OF_ONOS=3 NUM_OF_ATOMIX=3 flags set the number of Atomix nodes and ONOS nodes.

As usual one can add as many other options, for example CONFIG_SADIS=y.

GENERATED CONFIGURATION

When the voltha script is run it generates a file that contains the configuration settings. This file will be named $NAME-env.sh. The user can source this file to set the configuration as well as establish key environment variables in order to access VOLTHA, including:

After voltha up is run, it is useful to source this file.

QUICK CHECK

After source the $NAME-env.sh file, you should be able to access VOLTHA via the control application voltctl. To validate this you can use the following command

voltctl version

and should see output similar to

Client:
 Version        1.0.14
 Go version:    go1.12.8
 Vcs reference: 086629f0403fe67213fa0df5dc4d7b7ee317cbac
 Vcs dirty:     false
 Built:         2020-03-03T13:48:00Z
 OS/Arch:       linux/amd64

Cluster:
 Version        2.3.3-dev
 Go version:    1.13.8
 Vcs feference: aa8bd4dcc3510caf2c5362106d9bff2852663d31
 Vcs dirty:     false
 Built:         2020-03-06T16:16:47Z
 OS/Arch:       linux/amd64

If you've run the voltha script with WITH_BBSIM=y you can now create a BBSIM OLT with

voltctl device create -t openolt -H bbsim0.voltha.svc:50060

TROUBLESHOOTING

When VOLTHA is installed the install log is written to the file install-$NAME.log. If the install appears stalled or is not completing consulting this file may indicate the reason.

Similarly, when VOLTHA is uninstalled down-$NAME.log is written and should be consulted in the event of an error or unexpected result.