Skip to content

Latest commit

 

History

History
192 lines (135 loc) · 5.98 KB

development.md

File metadata and controls

192 lines (135 loc) · 5.98 KB

Developing Cluster API Provider Azure

Contents

Setting up

Base requirements

  1. Install go
    • Get the latest patch version for go v1.11.
  2. Install jq
    • brew install jq on MacOS.
  3. Install gettext package
    • brew install gettext && brew link --force gettext on MacOS.
  4. Install KIND
    • go get sigs.k8s.io/kind.
  5. Install bazel
  6. Configure Python 2.7+ with pyenv if your default is Python 3.x.

Get the source

go get -d sigs.k8s.io/cluster-api-provider-azure

Ensure you have updated the vendor directory with:

cd "$(go env GOPATH)/src/sigs.k8s.io/cluster-api-provider-azure"
make dep-ensure

Get familiar with basic concepts

This provider is modeled after the upstream Cluster API project. To get familiar with Cluster API resources, concepts and conventions, refer to the Cluster API gitbook.

Dev manifest files

Part of running cluster-api-provider-azure is generating manifests to run. Generating dev manifests allows you to test dev images instead of the default releases.

Dev images

Container registry

Any public container registry can be leveraged for storing cluster-api-provider-azure container images.

Developing

Change some code!

Manual Testing

Setting up the environment

Your environment must have the Azure credentials as outlined in the getting started prerequisites section

Building and pushing dev images

  1. Login to your container registry using docker login.

    e.g., docker login quay.io

  2. To build images with custom tags and push to your custom image registry, run the make docker-build as follows:

    REGISTRY="<container-registry>" MANAGER_IMAGE_TAG="<image-tag>" make docker-build

  3. Push your docker images:

    REGISTRY="<container-registry>" MANAGER_IMAGE_TAG="<image-tag>" make docker-push

Build manifests

NOTE: It's expected that some set of Azure credentials are available at the time, either as environment variable, or some other SDK-supported method.

Whenever you are working on a branch, you will need to generate manifests using:

make clean # Clean up any previous manifests

REGISTRY="<container-registry>" MANAGER_IMAGE_TAG="<image-tag>" RESOURCE_GROUP="<resource-group>" CLUSTER_NAME="<cluster-name>" make manifests

You will then have a sample cluster and machine manifest in: /cmd/clusterctl/examples/azure/out and a provider components file to use with clusterctl in cmd/clusterctl/examples/azure/out/provider-components.yaml

Creating a test cluster

Generate custom binaries:

make binaries

Ensure kind has been reset:

make kind-reset

make create-cluster will launch a bootstrap cluster and then run the generated manifests creating a target cluster in Azure.

If you're interested in creating the cluster with verbose logging, you can instead run:

time clusterctl create cluster -v 10 \
--provider azure \
--bootstrap-type kind \
-m ./cmd/clusterctl/examples/azure/out/machines.yaml \
-c ./cmd/clusterctl/examples/azure/out/cluster.yaml \
-p ./cmd/clusterctl/examples/azure/out/provider-components.yaml \
-a ./cmd/clusterctl/examples/azure/out/addons.yaml

While clusterctl is running, you can optionally follow the controller logs in a separate window as follows:

export KUBECONFIG="$(kind get kubeconfig-path --name="clusterapi")" # Export the kind kubeconfig

time kubectl get po -o wide --all-namespaces -w # Watch pod creation until azure-provider-controller-manager-0 is available

kubectl logs azure-provider-controller-manager-0 -n azure-provider-system -f # Follow the controller logs

After this is finished you will have a kubeconfig copied locally. You can debug most issues by SSHing into the instances that have been created and reading /var/lib/waagent/custom-script/download/0/stdout.

Submitting PRs and testing

Pull requests and issues are highly encouraged! If you're interested in submitting PRs to the project, please be sure to run some initial checks prior to submission:

make lint # Runs a suite of quick scripts to check code structure
make test # Runs tests on the Go code

Executing unit tests

make test executes the project's unit tests. These tests do not stand up a Kubernetes cluster, nor do they have external dependencies.

Automated Testing

Mocks

Mocks are set up using Bazel, see build

If you then want to use these mocks with go test ./..., run

make copy-genmocks