dev_tilt - OpenNebula/cluster-api-provider-opennebula GitHub Wiki

In order to be able to easily develop and debug CAPONE we can use kind and Tilt for enable hot deploy in our test cluster with rapid iterative builds. The debugging process is done through the Core Cluster API repository scripts. For more info about the process, take a look to the Cluster API Handbook.

For being able to debug our cluster API provider, we added a tilt-provider.yaml file in the CAPONE repository root folder. This file will be referenced from the tilt-settings.yaml, created by us in the Core Cluster API repository, which contents will be loaded by the Cluster API repository Tiltfile script for configuring the Tilt deployment.

As described in the Cluster API documentation:

• Docker: v19.03 or newer
• kind: v0.25.0 or newer
• Tilt: v0.30.8 or newer
• helm: v3.7.1 or newer (only necessary if we are going to deploy the observability suite)

You can deploy the test management cluster watched by Tilt following the instructions below:

1. Download the Cluster API repository locally. It's recommended to download it inside the $GOPATH in order to avoid any issue with the code generation tools:

   $ mkdir -p $GOPATH/src/github.com/kubernetes-sigs/cluster-api
   $ git clone [email protected]:kubernetes-sigs/cluster-api.git \
       $GOPATH/src/github.com/kubernetes-sigs/cluster-api
   $ cd $GOPATH/src/github.com/kubernetes-sigs/cluster-api
   

2. Add the following tilt-settings.yaml file in the Core Cluster API repository repository root folder with the following contents:

   default_registry: "localhost:5000"
   
   provider_repos:
   - /local/path/to/repo/cluster-api-provider-opennebula
   
   enable_providers:
   - opennebula-infrastructure
   
   extra_args:
     core:
       - "--v=4"
     opennebula-infrastructure:
       - "--v=4"
   
   debug:
    opennebula-infrastructure:
      continue: true
      port: 30000
   

   • The default_registry is automatically deployed in the management cluster when executing tilt and kind through the cluster api Makefile, so it should not be changed.
   • The provider_repos should point to your local cluster-api-provider-opennebula repository.
   • The kustomize_substitutions should contain the same info that you load from the .env file used in CAPONE for deploying the management cluster (remember to fix the ONE_XMLRPC and the ONE_AUTH values of this section).
   • We also increase the verbosity level for CAPONE infrastructure provider using the extra_args fields.

3. Once you have created the tilt-settings.yaml file in the Core Cluster API repository, execute the following makefile recipe from the root of that repository:

    $ make tilt-up
   

   This should launch a management cluster with kind and the CAPONE infrastructure controller:

   Tilt started on http://localhost:10350/
    v0.34.0, built 2025-03-12
   
    (space) to open the browser
    (s) to stream logs (--stream=true)
    (t) to open legacy terminal mode (--legacy=true)
    (ctrl-c) to exit
   

   You can check if there has been any problem with the Tilt managed workload deployment pressing the bar button from the tilt console. This will open a browser window with all the information.

4. Check the controllers running in the management cluster (you should already have the kubeconfig file imported, if not you can export it with the command kind export kubeconfig --name <cluster_name> --kubeconfig <path>):

   ❯ kubectl get pods -A
   NAMESPACE                   NAME                                                     READY   STATUS    RESTARTS   AGE
   capi-system                 capi-controller-manager-76fcd986b8-xpxqc                 1/1     Running   0          116s
   capone-system               capone-controller-manager-944cf67c8-jh7hf                1/1     Running   0          110s
   [...]
   

   As you can see we have the core CAPI controller manager (capi-controller-manager-...) as well as our CAPONE controller manager (capone-controller-manager-...) deployed and running.

   Any change to our provider code and it will automatically synchronized to our management cluster pod through Tilt.

Now, we can start debugging the provider. For doing so, before deploying the workload cluster, we can attach to the containers running in the management cluster in the port specified in the tilt-settings.yaml file (this is the port where delve is listening). For instance, if we are using VSCode, we can set the following launch configuration with alaunch.json file: { "version": "0.2.0", "configurations": [ { "name": "Connect to server", "type": "go", "request": "attach", "mode": "remote", "remotePath": "${workspaceFolder}", "port": 30000, "host": "127.0.0.1" } ] }

Remember to set any breakpoint you need in the code. Now, we are ready for deploying the workload and start debugging. For deploying the workload, we can execute the one-apply makefile recipe in the CAPONE repository (this will generate the workload kubernetes manifests with kustomize and deploy them to the current kubernetes context cluster). Remember to properly set the .env file parameters before:

 $ make one-apply

Your debugger client should stop at the given breakpoint and you should be able to analyze your code.

For deleting the workload cluster corresponding in OpenNebula, you should delete the workload cluster objects in the management cluster. You can easily do that through the following makefile recipe in the CAPONE repo Makefile:

$ make one-delete

Once the workload cluster OpenNebula infrastructure has been deleted, you can delete the management cluster calling the following makefile recipe from the core CAPI repository Makefile:

$ make clean-tilt

The kind cluster should be deleted and no temporary build files should remain in the core CAPI repository after that.