Skip to content

Latest commit

 

History

History
100 lines (72 loc) · 4.42 KB

development.md

File metadata and controls

100 lines (72 loc) · 4.42 KB

Developing Cluster API Provider Hetzner

Developing our provider is quite easy. First, you need to install some base requirements. Second, you need to follow the quickstart documents to set up everything related to Hetzner. Third, you need to configure your tilt set-up. After having done those three steps, you can start developing with the local Kind cluster and the Tilt UI to create one of the different workload clusters that are already pre-configured.

Install Base requirements

In order to develop with Tilt, there are a few requirements. You can use the following command to check whether the versions of the tools are up-to-date and to install ones that are missing (for both mac & linux): make install-dev-prerequisites

This ensures the following:

  • clusterctl
  • ctlptl (required)
  • go (required)
  • helm (required)
  • helmfile
  • kind (required)
  • kubectl (required)
  • packer
  • tilt (required)
  • hcloud

Some of them like helmfile or packer are not needed for developing the controller, but very helpful if you are developing images or stuff for production use.

Preparing Hetzner project

For more information, please see here.

Setting Tilt up

You need to create a tilt-settings.json file and specify the values you need. Here is an example:

{
  "kustomize_substitutions": {
      "HCLOUD_TOKEN": "<hcloud-token>",
      "HCLOUD_SSH_KEY": "test",
      "HCLOUD_REGION": "fsn1",
      "CONTROL_PLANE_MACHINE_COUNT": "3",
      "WORKER_MACHINE_COUNT": "3",
      "KUBERNETES_VERSION": "v1.24.0",
      "HCLOUD_IMAGE_NAME": "1.24.0-ubuntu-20.04-containerd",
      "HCLOUD_CONTROL_PLANE_MACHINE_TYPE": "cpx31",
      "HCLOUD_WORKER_MACHINE_TYPE": "cpx31",
      "CLUSTER_NAME": "testing",
      "HETZNER_SSH_PUB_PATH": "<path-to-public-ssh-key>",
      "HETZNER_SSH_PRIV_PATH": "<path-to-private-ssh-key>",
      "HETZNER_ROBOT_USER": "<robot-user>",
      "HETZNER_ROBOT_PASSWORD": "<robot-password>"
  },
  "talos-bootstrap": "false"
}

The whole reference can be found here.

Developing with Tilt

tilt

Provider Integration development requires a lot of iteration, and the “build, tag, push, update deployment” workflow can be very tedious. Tilt makes this process much simpler by watching for updates and automatically building and deploying them. To build a kind cluster and to start Tilt, run:

make tilt-up

To access the Tilt UI please go to: http://localhost:10350

Once your kind management cluster is up and running, you can deploy a workload cluster. This could be done through the Tilt UI, by pressing one of the buttons in the top right corner, e.g. "Create Workload Cluster - without Packer". This triggers the make create-workload-cluster, which uses the environment variables (we defined in the tilt-settings.json) and the cluster-template. Additionally, it installs cilium as CNI.

If you update the API in some way, you need to run make generate in order to generate everything related to kubebuilder and the CRDs.

To tear down the workload cluster press the "Delete Workload Cluster" button. After a few minutes the resources should be deleted.

To tear down the kind cluster, use:

$ make delete-cluster

To delete the registry, use: make delete-registry or make delete-cluster-registry.

If you have any trouble finding the right command, then you can use make help to get a list of all available make targets.

Submitting PRs and testing

Pull requests and issues are highly encouraged! For more information, please have a look in the Contribution Guidelines

There are two important commands that you should make use of before creating the PR.

With make verify you can run all linting checks and others. Make sure that all of these checks pass - otherwise the PR cannot be merged. Note that you need to commit all changes for the last checks to pass.

With make test all unit tests are triggered. If they fail out of nowhere, then please re-run them. They are not 100% stable and sometimes there are tests failing due to something related to Kubernetes' envtest.

With make generate new CRDs are generated, this is necessary if you change the api.

Running local e2e test

If you are interested in running the E2E tests locally, then you can use the following commands:

export HCLOUD_TOKEN=<your-hcloud-token>
make test-e2e