This section describes a typical workflow for developing the CORD control plane. This workflow does not include any data plane elements (e.g., the underlying switching fabric or access devices).
Setting Up a Local Development Environment
It is straightforward to set up a local Kubernetes environment on your laptop. The recommended way to do this is to use Minikube. This guide assumes you have done that. See the Single-Node case in the Installation Guide for more information, or you can go directly to the documentation for Minikube: https://kubernetes.io/docs/getting-started-guides/minikube/#installation
Note: If you are going to do development on Minikube you may want to increase its memory from the default 512MB. You can do this using this command to start Minikube:
minikube start --cpus 2 --memory 4096
In addition to Minikube running on your laptop, you will also need to install Helm: https://docs.helm.sh/using_helm/#installing-helm.
Once both Helm and Minikube are installed, you can deploy the core components of XOS, along with the services that make up, for example, the R-CORD profile. This uses images published on DockerHub:
In this folder you can choose from the different charts which one to deploy. For example to deploy R-CORD you can follow this guide
Deploy a Single Instance of Kafka
Some profiles require a
kafka message bus to work properly.
If you need to deploy it for development purposes, a single instance
deployment will be enough. You can do so as follows:
helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator install --name cord-kafka incubator/kafka -f examples/kafka-single.yaml
Making and Deploying Changes
Assuming you have
downloaded the CORD source code and the entire
source tree for CORD is under
~/cord, you can edit and re-deploy the
code as follows.
Note: To develop a single synchronizer you may not need the full CORD source, but this assume that you have a good knowledge of the system and you know what you’re doing.
First you will need to point Docker to the one provided by Minikube (note that you don’t need to have docker installed, as it comes with the Minikube installation).
eval $(minikube docker-env)
You will then need to build the containers from source:
cd ~/cord/automation-tools/developer python imagebuilder.py -f ../../helm-charts/examples/filter-images.yaml -x
At this point, the images containing your changes will be available in the Docker environment used by Minikube.
Note: In some cases you can rebuild a single docker image to make the process faster, but this assume that you have a good knowledge of the system and you know what you’re doing.
All that is left is to teardown and re-deploy the containers.
helm del --purge <chart-name> helm dep update <cart-name> helm install <chart-name> -n <chart-name> -f examples/image-tag-candidate.yaml -f examples/imagePullPolicy-IfNotPresent.yaml
In some cases it is possible to use the
helm upgrade command,
but if you made changes to the XOS models we suggest you redeploy
Note: if your changes are only in the synchronizer steps, after rebuilding the containers, you can just delete the corresponding POD and kubernetes will restart it with the new image.
Pushing Changes to a Remote Registry
If you have a remote POD that you want to test your changes on, you need to push your docker images to a registry that can be accessed from the POD.
The way we recommend doing this is via a private docker-registry. You can find more informations about what a docker-registry is here.
Tag and Push Images to the Docker Registry
For the images to be consumed on the Kubernetes cluster, they need to be first tagged, and pushed to the local registry:
Supposing your docker-registry address is:
and that your original image name is called:
you'll need to tag the image as
For example, you can use the docker tag command to do this:
docker tag xosproject/vsg-synchronizer:candidate 192.168.0.1:30500/xosproject/vsg-synchronizer:candidate
Now, you can push the image to the registry. For example, with docker push:
docker push 192.168.0.1:30500/xosproject/vsg-synchronizer:candidate
The image should now be in the local docker registry on your cluster.
Use the tag-and-push Script
Sometimes you may need to download, tag and push lots of images. This can become a long and error prone operation if done manually. For this reason, we provide an optional tool that automates the tag and push procedures. The script can be found here.