This repository holds the translation layer between the VOLTHA Northbound APIs and the BBF yang model, enabling VOLTHA to be integrated into a full fledged BBF Cloud CO deployment.

Clone this repo:

Branches

  1. aa7a048 Add support for user-friendly names in YANG data with aliases in KV store by Elia Battiston · 1 year, 8 months ago master
  2. a133364 Add initial support for provisioning and removing services, getting service data by Elia Battiston · 1 year, 9 months ago
  3. 4750d3c Add NETCONF notification for ONU activation and Kafka client to receive events, update dependencies by Elia Battiston · 1 year, 10 months ago
  4. d10fe3c 1. Fix Dockerfile.builder file for an updated version of Git. by Girish Gowdra · 2 years ago
  5. 589addb [VOL-4673] Initial translation of data inside mountpoint by Elia Battiston · 2 years, 1 month ago

Northbound BBF Adapter

The Northbound BBF Adapter is a translation layer between the VOLTHA Northbound APIs and the BBF yang model, enabling VOLTHA to be integrated into a full fledged BBF Cloud CO deployment.

Architecture

The Northbound BBF Adapter is implemented as a plugin for the sysrepo data store. Using libsysrepo, the adapter is able to act upon requests coming from NETCONF clients through the netopeer2 NETCONF server. A deployment of the adapter's container includes an instance of netopeer2 and the bbf-adapter process itself.

bbf-adapter-architecture

Deployment

For information on how to deploy the BBF Adapter, please refer to deploy.md in the docs folder.

Building

The default credentials used to authenticate to the netopeer2 server in the BBF adapter's container are voltha:onf.

An image with custom credentials can be built by running the following command:

NETCONF_USER=<username> NETCONF_PASSWORD=<password> make build

Additional doucmentation

Further documentation for the adapter's development can be found in the docs folder.

Development make targets

The Makefile contains many commands that are useful in development:

build                     : Alias for 'docker build'
clean                     : Removes any local filesystem artifacts generated by a build
distclean                 : Removes any local filesystem artifacts generated by a build or test run
docker-build              : Build the BBF Adapter docker container
docker-kind-load          : Load docker images into a KinD cluster
docker-push               : Push the docker images to an external repository
help                      : Print help for each Makefile target
lint-dockerfile           : Perform static analysis on Dockerfile
lint                      : Run all lint targets
lint-mod                  : Verify the Go dependencies
local-lib-go              : Copies a local version of the voltha-lib-go dependency into the vendor directory
local-protos              : Copies a local version of the voltha-protos dependency into the vendor directory
mod-update                : Update go mod files
sca                       : Runs static code analysis with the golangci-lint tool
test                      : Run unit tests

Some highlights:

  • It's recommended that you run the lint, sca, and test targets before submitting code changes.

  • The docker-* targets for building and pushing Docker images depend on the variables DOCKER_REGISTRY, DOCKER_REPOSITORY, and DOCKER_TAG as described in the CORD documentation

  • If you make changes the dependencies in the go.mod file, you will need to run make mod-update to update the go.sum and vendor directory.

Building with a Local Copy of voltha-protos or voltha-lib-go

If you want to build/test using a local copy of the voltha-protos or voltha-lib-go libraries this can be accomplished by using the environment variables LOCAL_PROTOS and LOCAL_LIB_GO. These environment variables should be set to the filesystem path where the local source is located, e.g.:

export LOCAL_PROTOS=/path/to/voltha-protos
export LOCAL_LIB_GO=/path/to/voltha-lib-go

Then run make local-protos and/or make local-lib-go as is appropriate to copy them into the vendor directory.

NOTE: That the files in the vendor directory are no longer what is in the most recent commit, and it will take manual git intervention to put the original files back.