Development and Testing

Development Environment setup

Install the latest versions of the following tools:

• Golang
• Docker
• Helm
• kubectl
• minikube

Install Golang at /usr/local/go.

The ideal development machine is a Ubuntu VM with approximately 8 GB of memory and about 16 GB of disk. For example, an Amazon EC2 t2.medium instance with the latest Ubuntu AMI and 16 GB of disk space.

Setup Paths

If you are on Ubuntu/Mac OS use $HOME in the below commands; if you are on Windows use %HOME%:

mkdir -p $HOME/go/src/github.com/cloud-ark
cd $HOME/go/src/github.com/cloud-ark
git clone --depth 1 https://github.com/cloud-ark/kubeplus.git
export KUBEPLUS_HOME=$HOME/go/src/github.com/cloud-ark/kubeplus
export GOROOT=/usr/local/go
export PATH=$PATH:/usr/local/go/bin

Suppose you are working on some feature. Here are the steps of how to test it locally.

Start test cluster

Start the minikube cluster and connect your Docker cli to the Docker daemon on minikube

minikube start
eval $(minikube docker-env)

Development and testing procedure

You must deploy KubePlus with Docker images built with your local changes to test your local changes. For this, build the appropriate component and then deploy KubePlus using the Helm install command, where the built component's image is passed in as a parameter to the Helm install command. For building each component, a build script is provided in the appropriate folder. Check the build script to see the image tags that will be created. Feel free to modify the build script to change the image tags as appropriate. Note that when building a component to test local changes, pass "latest" as the parameter to the build script. The build script only tries to push images to KubePlus's public image registry, which are not tagged as "latest". So when you test your local changes, pass the "latest" parameter to the build script. This will ensure that images tagged as "latest" will be created, and the build script will not try to push the image to the public registry.

Build components

Here are the steps to build various components. Build the appropriate component corresponding to the feature that you are working on.

mutating-webhook

cd $KUBEPLUS_HOME/mutating-webhook
export GO111MODULE=on; go get github.com/googleapis/[email protected]
./build-artifact.sh latest
docker images

helm-pod

cd $KUBEPLUS_HOME/platform-operator/helm-pod/
go mod vendor
./build-artifact.sh latest
docker images

platform-operator

cd $KUBEPLUS_HOME/platform-operator
./build-artifact.sh latest
docker images

crd-registration-helper

cd $KUBEPLUS_HOME/deploy
./build-artifact-kubeconfiggenerator.sh latest
docker images

webhook-init-container

cd $KUBEPLUS_HOME/deploy
./build-artifact.sh latest
docker images

Install KubePlus

Install KubePlus with the image of the latest components.

cd $KUBEPLUS_HOME
export KUBEPLUS_NS=default
apiserver=`kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'`
pip3 install pyyaml
python3 provider-kubeconfig.py -s $apiserver create $KUBEPLUS_NS

Check $KUBEPLUS_HOME/deploy/kubeplus-chart/values.yaml to find the variable names representing the various KubePlus component containers. When installing the KubePlus chart, override the appropriate container that you built. The variable names for different KubePlus components are as follows:

MUTATING_WEBHOOK
WEBHOOK_INIT_CONTAINER
CRD_REGISTRATION_HELPER
PLATFORM_OPERATOR
CONSUMERUI
HELMER
RESOURCE_CLEANER

For example, if you modify mutating-webhook, the helm install command will be:

helm install kubeplus $KUBEPLUS_HOME/deploy/kubeplus-chart --set MUTATING_WEBHOOK=gcr.io/cloudark-kubeplus/pac-mutating-admission-webhook:latest

Run tests

Check that KubePlus is running:

kubectl get pods -n $KUBEPLUS_NS

Once KubePlus is up, run the tests:

cd $KUBEPLUS_HOME/tests
python3 -m unittest -v tests

If tests pass, send a PR for your feature. Make sure to create a GitHub issue first and link it in the commit message.