Gitiles
Code Review Sign In
gerrit.opencord.org / voltha-northbound-bbf-adapter / refs/heads/master
commitaa7a048712735fc6567994fd529b5208ff339ab0[log] [tgz]
authorElia Battiston <elia.battiston@radisys.com>Wed Aug 17 12:24:02 2022 +0000
committerElia Battiston <elia.battiston@radisys.com>Tue Aug 23 08:57:29 2022 +0000
tree8702b818e582a0059efbde9732cea6532da4247e
parenta133364c3595d4530ba8c6a70512be2b5ab64c0f [diff]
Add support for user-friendly names in YANG data with aliases in KV store

Change-Id: I8b4fbb290dfb467b401e8cf20b825ddbb3bf897e
326 files changed
tree: 8702b818e582a0059efbde9732cea6532da4247e
  1. .dockerignore
  2. .gitignore
  3. .gitreview
  4. .golangci.yml
  5. CODE_OF_CONDUCT.md
  6. Makefile
  7. README.md
  8. VERSION
  9. build/
  10. cmd/
  11. docs/
  12. examples/
  13. go.mod
  14. go.sum
  15. internal/
  16. vendor/
README.md

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.