User Story

In creating a manifest for HelmChartProxy, I would like to add support for other fields of the labelselector, such as matchExpressions.

Anything else you would like to add:

This issue is related to PR #14.

/kind feature

What steps did you take and what happened:
Got 'HelmInstallOrUpgradeFailed' error, in particular it is 'x509: certificate signed by unknown authority' when trying to use helm oci to install helm chart.

It is similar to this example: https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm/blob/main/config/samples/postgres.yaml, just the registry is with internal CA certificate, not public.

It worked when I tried to manually use 'helm install ... oci:// ...'. command to install the chart.

What did you expect to happen:
CAAPH should work with internal repository with helm chart stored as OCI.

Anything else you would like to add:
No

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

This would allow some basic protection against invalid YAML from landing in the project.

/kind feature

What steps did you take and what happened:
caaph-controller crashes with invalid memory address or nil pointer dereference.

kgpwide -n caaph-system NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES caaph-controller-manager-7747fbcb95-vb2sp 1/2 CrashLoopBackOff 13 (4m51s ago) 61m 10.244.0.13 capi-test-control-plane <none> <none>

Relevant log lines:
[manager] I0206 09:57:30.284401 14 controller.go:117] "Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="default/metallb-config-gkhatri-wkcl1-jmqbf" namespace="default" name="metallb-config-gkhatri-wkcl1-jmqbf" reconcileID=d0609e86-5599-4236-be98-9056247b6425 [manager] panic: runtime error: invalid memory address or nil pointer dereference [recovered] [manager] panic: runtime error: invalid memory address or nil pointer dereference [manager] [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1e6b622]

Full log:
[manager] I0206 09:57:12.888703 14 request.go:601] Waited for 1.035578641s due to client-side throttling, not priority and fairness, request: GET:[https://10.96.0.1:443/apis/cluster.x-k8s.io/v1alpha4?timeout=32s](https://10.96.0.1/apis/cluster.x-k8s.io/v1alpha4?timeout=32s) [manager] I0206 09:57:13.042136 14 listener.go:44] "controller-runtime/metrics: Metrics server is starting to listen" addr="127.0.0.1:8080" [manager] I0206 09:57:13.043339 14 webhook.go:124] "controller-runtime/builder: Registering a mutating webhook" GVK="addons.cluster.x-k8s.io/v1alpha1, Kind=HelmChartProxy" path="/mutate-addons-cluster-x-k8s-io-v1alpha1-helmchartproxy" [manager] I0206 09:57:13.043496 14 server.go:148] "controller-runtime/webhook: Registering webhook" path="/mutate-addons-cluster-x-k8s-io-v1alpha1-helmchartproxy" [manager] I0206 09:57:13.043606 14 webhook.go:153] "controller-runtime/builder: Registering a validating webhook" GVK="addons.cluster.x-k8s.io/v1alpha1, Kind=HelmChartProxy" path="/validate-addons-cluster-x-k8s-io-v1alpha1-helmchartproxy" [manager] I0206 09:57:13.043681 14 server.go:148] "controller-runtime/webhook: Registering webhook" path="/validate-addons-cluster-x-k8s-io-v1alpha1-helmchartproxy" [manager] I0206 09:57:13.043851 14 webhook.go:124] "controller-runtime/builder: Registering a mutating webhook" GVK="addons.cluster.x-k8s.io/v1alpha1, Kind=HelmReleaseProxy" path="/mutate-addons-cluster-x-k8s-io-v1alpha1-helmreleaseproxy" [manager] I0206 09:57:13.043931 14 server.go:148] "controller-runtime/webhook: Registering webhook" path="/mutate-addons-cluster-x-k8s-io-v1alpha1-helmreleaseproxy" [manager] I0206 09:57:13.044037 14 webhook.go:153] "controller-runtime/builder: Registering a validating webhook" GVK="addons.cluster.x-k8s.io/v1alpha1, Kind=HelmReleaseProxy" path="/validate-addons-cluster-x-k8s-io-v1alpha1-helmreleaseproxy" [manager] I0206 09:57:13.044107 14 server.go:148] "controller-runtime/webhook: Registering webhook" path="/validate-addons-cluster-x-k8s-io-v1alpha1-helmreleaseproxy" [manager] I0206 09:57:13.044202 14 main.go:133] "setup: starting manager" [manager] I0206 09:57:13.044270 14 server.go:216] "controller-runtime/webhook/webhooks: Starting webhook server" [manager] I0206 09:57:13.044320 14 internal.go:366] "Starting server" path="/metrics" kind="metrics" addr="127.0.0.1:8080" [manager] I0206 09:57:13.044327 14 internal.go:366] "Starting server" kind="health probe" addr="[::]:8081" [manager] I0206 09:57:13.044543 14 leaderelection.go:248] attempting to acquire leader lease caaph-system/5a2dee3e.cluster.x-k8s.io... [manager] I0206 09:57:13.044692 14 certwatcher.go:131] "controller-runtime/certwatcher: Updated current TLS certificate" [manager] I0206 09:57:13.044866 14 server.go:270] "controller-runtime/webhook: Serving webhook server" host="" port=9443 [manager] I0206 09:57:13.044897 14 certwatcher.go:85] "controller-runtime/certwatcher: Starting certificate watcher" [manager] I0206 09:57:30.039582 14 leaderelection.go:258] successfully acquired lease caaph-system/5a2dee3e.cluster.x-k8s.io [manager] I0206 09:57:30.039822 14 controller.go:185] "Starting EventSource" controller="helmchartproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmChartProxy" source="kind source: *v1alpha1.HelmChartProxy" [manager] I0206 09:57:30.039887 14 controller.go:185] "Starting EventSource" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" source="kind source: *v1alpha1.HelmReleaseProxy" [manager] I0206 09:57:30.039897 14 controller.go:185] "Starting EventSource" controller="helmchartproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmChartProxy" source="kind source: *v1beta1.Cluster" [manager] I0206 09:57:30.039926 14 controller.go:185] "Starting EventSource" controller="helmchartproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmChartProxy" source="kind source: *v1alpha1.HelmReleaseProxy" [manager] I0206 09:57:30.039949 14 controller.go:193] "Starting Controller" controller="helmchartproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmChartProxy" [manager] I0206 09:57:30.039928 14 controller.go:193] "Starting Controller" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" [manager] I0206 09:57:30.141318 14 controller.go:227] "Starting workers" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" worker count=10 [manager] I0206 09:57:30.141369 14 controller.go:227] "Starting workers" controller="helmchartproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmChartProxy" worker count=10 [manager] I0206 09:57:30.284401 14 controller.go:117] "Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="default/metallb-config-gkhatri-wkcl1-jmqbf" namespace="default" name="metallb-config-gkhatri-wkcl1-jmqbf" reconcileID=d0609e86-5599-4236-be98-9056247b6425 [manager] panic: runtime error: invalid memory address or nil pointer dereference [recovered] [manager] panic: runtime error: invalid memory address or nil pointer dereference [manager] [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1e6b622] [manager] [manager] goroutine 490 [running]: [manager] sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile.func1() [manager] /home/administrator/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:118 +0x1f4 [manager] panic({0x210c220, 0x3ba7850}) [manager] /home/administrator/sdk/go1.19.4/src/runtime/panic.go:884 +0x212 [manager] cluster-api-addon-provider-helm/internal.UpgradeHelmReleaseIfChanged({0x2839e08, 0xc000f2e900}, {0xc000865800, 0x15da}, {{{0xc000c17c90, 0x7}, {0xc000c17c97, 0x7}, {0xc000c17ca0, 0xd}, ...}, ...}, ...) [manager] /home/administrator/dev/cluster-api-addon-provider-helm/internal/helm_operations.go:240 +0x802 [manager] cluster-api-addon-provider-helm/internal.InstallOrUpgradeHelmRelease({0x2839e08, 0xc000f2e900}, {0xc000865800, 0x15da}, {{{0xc000c17c90, 0x7}, {0xc000c17c97, 0x7}, {0xc000c17ca0, 0xd}, ...}, ...}) [manager] /home/administrator/dev/cluster-api-addon-provider-helm/internal/helm_operations.go:121 +0x13b [manager] cluster-api-addon-provider-helm/controllers/helmreleaseproxy.(*HelmReleaseProxyReconciler).reconcileNormal(0x28408e0?, {0x2839e08, 0xc000f2e900}, 0xc00110e240, {0xc000865800, 0x15da}) [manager] /home/administrator/dev/cluster-api-addon-provider-helm/controllers/helmreleaseproxy/helmreleaseproxy_controller.go:212 +0x398 [manager] cluster-api-addon-provider-helm/controllers/helmreleaseproxy.(*HelmReleaseProxyReconciler).Reconcile(0xc0008a3f80, {0x2839e08, 0xc000f2e900}, {{{0xc000c17c50, 0x7}, {0xc0008885d0, 0x22}}}) [manager] /home/administrator/dev/cluster-api-addon-provider-helm/controllers/helmreleaseproxy/helmreleaseproxy_controller.go:193 +0x109a [manager] sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile(0x2839d60?, {0x2839e08?, 0xc000f2e900?}, {{{0xc000c17c50?, 0x234fde0?}, {0xc0008885d0?, 0x404554?}}}) [manager] /home/administrator/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:121 +0xc8 [manager] sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc0001e9e00, {0x2839d60, 0xc000d19e80}, {0x21d5100?, 0xc000718180?}) [manager] /home/administrator/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:320 +0x33c [manager] sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc0001e9e00, {0x2839d60, 0xc000d19e80}) [manager] /home/administrator/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:273 +0x1d9 [manager] sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2() [manager] /home/administrator/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:234 +0x85 [manager] created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2 [manager] /home/administrator/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:230 +0x333 [manager] Exiting with code 2 [event: pod caaph-system/caaph-controller-manager-7747fbcb95-vb2sp] Back-off restarting failed container [event: pod caaph-system/caaph-controller-manager-7747fbcb95-vb2sp] Back-off restarting failed container [event: pod caaph-system/caaph-controller-manager-7747fbcb95-vb2sp] Back-off restarting failed container Detected container restart. Pod: caaph-controller-manager-7747fbcb95-vb2sp. Container: manager.

What did you expect to happen:
Expected caaph-controller pod to be in running state.

Anything else you would like to add:
The issue happens immediately after deploying caaph-controller

Environment:

• Cluster API version: 1.3.1, 1.3.3
• Cluster API Add-on Provider for Helm version:
• Kubernetes version: (use kubectl version): 1.24.1
• OS (e.g. from /etc/os-release): ubuntu 20.04

/kind bug

User Story

As a user I would like the option of dry run before installing helm charts through CAAPH to understand what exact changes will be made before the helmchartproxy is applied and k8s resources are created/updated.

Detailed Description

The dry run option should probably run helm template and kubectl diff the changes between the generated manifests and the actual resources running in all selected clusters and provide the diff output either in helmreleaseproxy or in a new CRD. This would help to get an idea of what exact changes will be made in which resources and clusters.

Anything else you would like to add:

I could add this as a step in a CI pipeline but the CI pipeline would have to interact with all workload clusters to run helm/kubectl commands against them to get the output which doesn't seem like an ideal scenario while using CAAPH to apply them through the management cluster.

/kind feature

User Story

As a user I would like to be able to use OCI-based registries to deploy my charts.

Detailed Description

Since Helm 3.8.0 OCI support is GA.

Now a Helm repository can be stored inside a OCI-based registry, it simplify the approach to distribute chart by having both chart and container in a common registry

We need to be able to define inside an HelmChartProxy an OCI Helm repo like

apiVersion: addons.cluster.x-k8s.io/v1alpha1
kind: HelmChartProxy
metadata:
  name: mychart
spec:
  clusterSelector:
    matchLabels:
      myChart: enabled
  repoURL: oci://my-harbor-registry/helm-repo
  chartName: mychart

We need also to be able to support any kind of private registry (auth, cert,...)

Anything else you would like to add:

I would expect it works out of the box

but for the moment I get the following error

manager E0517 17:05:23.932359       1 controller.go:326] "Reconciler error" err="error installing or updating chart with Helm on cluster cluster1: looks lik
e \"oci://my-harbor-registry/helm-repo\" is not a valid chart repository or cannot be reached: object required" controller="helmreleaseproxy" controllerGroup="addons.clust
er.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="default/cilium-cluster1-7x7fk" namespace="default" name="cilium-cluster1-7x7fk" reconcileID
=fc85a698-5cf0-4724-910b-dab00427499d

I not yet check the code

/kind feature

What steps did you take and what happened:

• create a cluster with a label that matches a hcp
• cluster gets deployed and so does the hrp
• remove the label so that the hcp should no longer match
• caaph crashes with panic (logs below)

I0627 14:48:42.192680       1 controller.go:228] "Starting workers" controller="helmchartproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmChartProxy" worker count=10
I0627 14:48:42.192770       1 controller.go:228] "Starting workers" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" worker count=10
I0627 14:48:42.450134       1 controller.go:118] "Observed a panic in reconciler: runtime error: invalid memory address or nil pointer dereference" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="daphne/openstack-cinder-csi-satellite-dev-tw4lh" namespace="daphne" name="openstack-cinder-csi-satellite-dev-tw4lh" reconcileID=80fff3d9-3315-4473-97ba-9bd6658543e8
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
  panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1f069ba]

goroutine 270 [running]:
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile.func1()
  sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:119 +0x1fa
panic({0x21bba80, 0x3cd1c80})
  runtime/panic.go:884 +0x212
sigs.k8s.io/cluster-api-addon-provider-helm/internal.generateHelmUninstallConfig(...)
  sigs.k8s.io/cluster-api-addon-provider-helm/internal/helm_operations.go:461
sigs.k8s.io/cluster-api-addon-provider-helm/internal.UninstallHelmRelease({0x290d608?, 0xc0007994d0?}, {0xc001028800?, _}, {{{0xc000680720, 0x7}, {0xc000680728, 0x6}, {0xc000680730, 0xd}, ...}, ...})
  sigs.k8s.io/cluster-api-addon-provider-helm/internal/helm_operations.go:482 +0x7a
sigs.k8s.io/cluster-api-addon-provider-helm/controllers/helmreleaseproxy.(*HelmReleaseProxyReconciler).reconcileDelete(0x29362f8?, {0x290d608, 0xc0007994d0}, 0xc000699440, {0xc001028800, 0x15da})
  sigs.k8s.io/cluster-api-addon-provider-helm/controllers/helmreleaseproxy/helmreleaseproxy_controller.go:259 +0x6c5
sigs.k8s.io/cluster-api-addon-provider-helm/controllers/helmreleaseproxy.(*HelmReleaseProxyReconciler).Reconcile(0xc000997020, {0x290d608, 0xc0007994d0}, {{{0xc000680700, 0x6}, {0xc0008338f0, 0x28}}})
  sigs.k8s.io/cluster-api-addon-provider-helm/controllers/helmreleaseproxy/helmreleaseproxy_controller.go:141 +0xaba
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile(0x290d608?, {0x290d608?, 0xc0007994d0?}, {{{0xc000680700?, 0x20a6360?}, {0xc0008338f0?, 0x0?}}})
  sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:122 +0xc8
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc0004b5a40, {0x290d560, 0xc000a17bc0}, {0x228af80?, 0xc00029e5e0?})
  sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:323 +0x38f
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc0004b5a40, {0x290d560, 0xc000a17bc0})
  sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:274 +0x1d9
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()
  sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:235 +0x85
created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2
  sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:231 +0x333

What did you expect to happen:
caaph should delete the helm installation and the hrp that corresponds to it

Anything else you would like to add:

• running manually a helm uninstall on the workload cluster fixes the issue
• i cannot get more detailed logs as there is no way to increase verbosity

Environment:

• Cluster API version: 1.4.2
• Cluster API Add-on Provider for Helm version: v0.1.0-alpha.7
• minikube/kind version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug

I got the bellow error when I want to install caaph :

Error response from daemon: manifest for registry.k8s.io/cluster-api-helm/cluster-api-helm-controller:v0.1.1-alpha.0 not found: manifest unknown: Failed to fetch "v0.1.1-alpha.0"

User Story

I'd like to add a status field in the HelmReleaseProxyStatus indicating the pods, dameon sets, config maps, etc. that were deployed in the Helm release.

Detailed Description

Since this Helm PR merged, we should be able to have support for this feature. It would, however, require bumping to Helm v3.11.0, which breaks the code by upgrading the k8s.io/api package from v0.25 to v0.26. I believe that it's because it conflicts with CAPI v1.3.2 but will need further investigation.

/kind feature

User Story
I would like to define some configuration resources before deploying Helm.

Detailed Description
When I deploy the config/samples/calico-cni.yaml. Tigera Operator allows you to define a ConfigMap named "kubernetes-services-endpoint" to modify the environment variables of Tigera Operator. However, when deploying Helm directly, this ConfigMap is not generated automatically. Therefore, you have to define it in the workload cluster first. Is there a better way for CAAPH to achieve this?

Anything else you would like to add:
For example, adding an optionsTemplate field to define the desired configuration resources, and deploying the resources defined in optionsTemplate before deploying the Helm resources.

apiVersion: addons.cluster.x-k8s.io/v1alpha1
kind: HelmChartProxy
metadata:
  name: calico-cni
spec:
  clusterSelector:
  # Target workload clusters with specific labels.
  #  matchLabels:
  #    calicoCNI: enabled
  # Target all workload clusters.
    matchLabels: {}
  releaseName: calico
  repoURL: https://docs.tigera.io/calico/charts
  chartName: tigera-operator
  namespace: kube-system
  valuesTemplate: |
    installation:
      cni:
        type: Calico
        ipam:
          type: HostLocal
      calicoNetwork:
        bgp: Disabled
        mtu: 1350
        ipPools:{{range $i, $cidr := .Cluster.spec.clusterNetwork.pods.cidrBlocks }}
        - cidr: {{ $cidr }}
          encapsulation: None
          natOutgoing: Enabled
          nodeSelector: all(){{end}}
  optionsTemplate: |
    apiVersion: v1
    data:
      KUBERNETES_SERVICE_HOST: example.com
      KUBERNETES_SERVICE_PORT: "6443"
    kind: ConfigMap
    metadata:
      name: kubernetes-services-endpoint
      namespace: kube-system

/kind feature

User Story

As a user i would like to be able to use private helm repositories to deploy charts. This is really necessary for charts that are built and maintained within a company and/or for air-gapped installations.

Detailed Description

I would expect something like this:

apiVersion: addons.cluster.x-k8s.io/v1alpha1
kind: HelmChartProxy
metadata:
  name: nginx-ingress
spec:
  clusterSelector:
    matchLabels:
      nginxIngressChart: enabled
  repoURL: https://helm.nginx.com/stable
  chartName: nginx-ingress
  credentialsRef:
    kind: Secret
    name: creds-for-private-helm-repo

Basically in the secret will be stored like username/pass to auth with the private helm repo.

Anything else you would like to add:

This might be already possible but i couldn't find something in the quick start and from a quick look in the code.

/kind feature

User Story

As a developer I would like to run real controller reconcile loop for better testing, i.e. update or full lifecycle

Detailed Description

It would be nice to run controller test with SetupWithManager in addition to the single Reconcile(...) function just one time.
This is a big limitation, as setup-envetest fake Kubernetes cluster already bootstrapped in unit tests but not utilized in integration.
No CR updates can be tested with single Reconcile approach, as well as some features, introduced on the Kubernetes API server level, i.e. metadata Observed value, ObjectRefrence, Finalizers, etc. are not allowed.

Anything else you would like to add:

It would be nice to add real reconcile integration tests inside the controller package in addition to the single Reconcile unit tests and before real e2e tests introduced in #147.

/kind feature

What steps did you take and what happened:
I tried to deploy the release v0.1.0-alpha.4 but the got an ImagePullBackOff after investigating I saw that there is no image for the v0.1.0-alpha.4 tag only for v0.1.0-alpha.1.
see: https://explore.ggcr.dev/?repo=registry.k8s.io%2Fcluster-api-helm%2Fcluster-api-helm-controller

What did you expect to happen:
I expect to successfully deploy the CAAPH controller

Environment:

• Cluster API Add-on Provider for Helm version: v0.1.0-alpha.4

/kind bug

User Story

As a developer/user/operator, I would like to retry a failed helm installation as a helm installation might be failing due to CRDs dependent on another helm chart not being installed yet.

Detailed Description
CAAPH controller start helm chart execution for all helmchartproxy objects almost parallely and doesn't wait for one helmreleaseproxy to get created. This causes issues when a helm chart is dependent on CRDs deployed by the previous helm chart. The dependent helm chart stays in Failed state forever. It seems the reconciler stops once helm install command has been executed on the cluster.

Anything else you would like to add:
It would really help if CAAPH supported a retry count parameter(Eg. retryCount: 5). helmReleaseProxy would get retried 5 times before giving up.

/kind feature

User Story

As a user/operator I would like to be able to use this provider to bootstrap addons on a workload cluster, but then allow the workload cluster to take over their management. This mode is currently supported for CRS and I think there are use cases for mirroring it here.

Detailed Description

Add a field to the HelmChartProxy to request a "one-shot" mode for the helm release. If this is turned on, the provider requeues the helm chart installation until it gets a successful install on the workload cluster and then forgets about the helm release. After a successful install, there should be no more reconciliation, drift-detection, deletions or anything happening on that helm release irrespectively of what happens on the management cluster or on the workload cluster.

The use case for this is bootstrapping components that are crucial for successful initialization of a cluster (CNI, cloud-controller, some workload-cluster package manager itself, etc...) but then delegating the subsequent management of such releases to the workload cluster itself (which might have its own package manager or its own lifecycle manager for helm releases).

/kind feature

User Story

As a user I would like to be able to use "clusterctl move" to backup/restore/move cluster api configs to another place/cluster. To use caaph to replace ClusterResourceSet for network cni deployment.

It seems "clusterctl move" currently works ok with ClusterResourceSet, but I don't see yaml being generated for hrp/hcp.

Detailed Description

clusterctl move to also work with hrp/hcp.

Anything else you would like to add:

none

/kind feature

If you have two HelmChartProxies selecting the same Cluster with the same release name, then they would both create their own HelmReleaseProxy. Each of those HelmReleaseProxies would try to install or update a Helm release with the same name leading to a collision.

User Story

As an operator I would like to be able to update helm values of a deployment after installation.

Detailed Description

As an operator, I aim to update the helm values of an installed application effortlessly. This necessity arises from our environment where numerous clusters operate seamlessly with standard values, yet a handful require additional configurations. We envision incorporating a values template within the Helmchartproxy, serving as a standard template that is only customized in exceptional scenarios. Something similar to the functionality provided by the helm upgrade command for updating values.

Traefik deployment is a good example for that. Most of our clusters and applications work on just an "web secure" entry point but in some cases we need to add an ssh service for example.
So it would be great to add these information among other things to the deployment or the helmreleaseproxy

additionalArguments:
  - "--entrypoints.ssh.address=:2222" 

ports:
  ssh:
    port: 2222 
    expose: true
    exposedPort: 2222  
    protocol: TCP

We want to avoid messing up the helm logic here so we think this needs to be integrated into the Helmchart-/Helmreleaseproxy in some case

Anything else you would like to add:

It's plausible that the desired functionality already exists or is not desired, and there might be a misunderstanding on our part, as we haven't discovered a method to implement this workflow yet. If such functionality is available, gaining further insights would be great

/kind feature

It would be good to set up the Dockerfile and make targets to build/push to a container registry (like GCR) so that people can try it out easily.

What steps did you take and what happened:
Deploy a HelmChartProxy and then change the namespace value. The install gets deleted from the current namespace, but it doesn't get reinstalled to the new namespace.

I found this in the logs:

E0319 23:30:02.231917       1 controller.go:329] "Reconciler error" err="Unable to continue with install: CustomResourceDefinition \"applications.argoproj.io\" in namespace \"\" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key \"meta.helm.sh/release-name\" must equal \"argo-cd-1710890996\": current value is \"argo-cd-1710874729\"; annotation validation error: key \"meta.helm.sh/release-namespace\" must equal \"argocd\": current value is \"default\"" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="default/argo-cd-argoclustercaaph-wwfjf" namespace="default" name="argo-cd-argoclustercaaph-wwfjf" reconcileID="894ea010-a219-450a-9f76-eb4741c8de97"

What did you expect to happen:
At a minimum it would be more clear what is happening. Ideally, it would just delete the install from the current namespace and install to the new namespace.

Environment:

• Cluster API version: 1.14.0
• Cluster API Add-on Provider for Helm version: v0.1.1-alpha.1
• Kubernetes version: (use kubectl version): docker-desktop K8s 1.29.1

/kind bug

User Story

As a maintainer of CAAPH, I would like to have simple, foolproof documentation that leads me through creating a product release.

Detailed Description

The targets and tooling for doing a release appear to be here, but no documentation. Trying to figure it out without a guide that contains specific steps and commands is fraught with peril.

Anything else you would like to add:

/kind feature
/area documentation

CAPI v1.5.0-beta.0 has been released and is ready for testing.
Looking forward to your feedback before CAPI 1.5.0 release, the 25th July 2023!

For quick reference

• CAPI v1.5.0-beta.0 release notes
• Shortcut to CAPI git issues

Following are the planned dates for the upcoming releases

User Story

As a operator I would like HelmChartProxy to watch for all workload cluster objects and not only the ones in its namespace.

Detailed Description

We have decide to create each workload cluster in a dedicated namespace. Having HelmChartProxy select workload cluster with the correct label only in its own namespace loses all interest in this case (you'd have to create as many HelmChartProxies as workload clusters to make it works).

It would be very interresting if we can indicate in the HelmChartProxy spec if it should work in a namespace or a cluster scoped to watch for workload cluster object to select.

/kind feature

User Story

As a developer and further operator/user I would like to have unique way for detecting successful updates for the HelmChartProxy objects.

Detailed Description

In case, we need to have unique and easy way for detecting successful updates of the HelmChartProxy objects, we should track and copy ObservedGeneration value from the ObjectMeta struct to the Status field in case of the ReadyCondition to be True. Otherwise, update detection can be a complex way, if controller or our system can be stuck, reboot or too slow.

Anything else you would like to add:

Cluster API contains patchHelper.Patch function with patch.WithStatusObservedGeneration{} for that which is embedded in the controller already. We just need to add ObservedGeneration field to the Status field and add tests for that.

/kind feature

Currently when trying to install caaph via clusterctl (1.5.2 version) gives the following:

❯ clusterctl init --addon helm                                                                                                                                                                  
Fetching providers
Error: failed to get provider components for the "helm" provider: failed to read "addon-components.yaml" from provider's repository "addon-helm": failed to download files from GitHub release v0.1.0-alpha.3-rc.0: failed to get file "addon-components.yaml" from "v0.1.0-alpha.3-rc.0" release

This is wrong in 2 ways:

• the version that is being installed is not the latest available: v0.1.0-alpha.3-rc.0 vs v0.1.0-alpha.10
• The v0.1.0-alpha.3-rc.0 version cannot be installed because in the release assets the components are add-on-components.yaml instead of addon-components.yaml that clusterctl expects

Defining a version such as clusterctl init --addon helm:v0.1.0-alpha.10 works just fine

/kind bug

What steps did you take and what happened:

1. Deploy HelmChartProxy to cluster1 where cluster1 is not reachable
2. Add another cluster2 where the same HelmChartProxy applies via using the same labels (this one does work)
3. Change/delete the label for Cluster1 so that the HelmChartProxy no longer applies to that cluster
4. The status of that HelmChartProxy still shows failure mode even though it no longer applies to that cluster

What did you expect to happen:

Status:
  Conditions:
    Last Transition Time:  2024-03-19T20:38:32Z
    Message:               Kubernetes cluster unreachable: Get "https://argocluster-azphsqsi.hcp.westus3.azmk8s.io:443/version": dial tcp: lookup argocluster-azphsqsi.hcp.westus3.azmk8s.io on 10.96.0.10:53: no such host    
    Reason:                HelmReleaseGetFailed @ HelmReleaseProxy/argo-cd-argocluster-rrf94
    Severity:              Error
    Status:                False
    Type:                  Ready
    Last Transition Time:  2024-03-19T20:38:32Z
    Message:               Kubernetes cluster unreachable: Get "https://argocluster-azphsqsi.hcp.westus3.azmk8s.io:443/version": dial tcp: lookup argocluster-azphsqsi.hcp.westus3.azmk8s.io on 10.96.0.10:53: no such host    
    Reason:                HelmReleaseGetFailed @ HelmReleaseProxy/argo-cd-argocluster-rrf94
    Severity:              Error
    Status:                False
    Type:                  HelmReleaseProxiesReady
    Last Transition Time:  2024-03-19T22:45:24Z
    Status:                True
    Type:                  HelmReleaseProxySpecsUpToDate
  Matching Clusters:
    API Version:        cluster.x-k8s.io/v1beta1
    Kind:               Cluster
    Name:               argoclustercaaph
    Namespace:          default
  Observed Generation:  9
Events:                 <none>

Environment:

• Cluster API version:
• Cluster API Add-on Provider for Helm version:
• minikube/kind version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

What steps did you take and what happened:
With a new k8s cluster with kube-proxy, delete its kubeproxy via command kubectl delete ds/kube-proxy -n kube-system, then kubectl apply the following yaml file 'cilium-cni.yaml':

apiVersion: addons.cluster.x-k8s.io/v1alpha1
kind: HelmChartProxy
metadata:
  name: cilium-cni
spec:
  clusterSelector:
    matchLabels:
      ciliumCNI: enabled
  releaseName: cilium
  repoURL: https://helm.cilium.io/
  chartName: cilium
  version: 1.13.4
  namespace: kube-system
  valuesTemplate: |
    kubeProxyReplacement: "strict"

Then label this cluster with command kubectl label cluster new-cluster-name ciliumCNI=enabled

It successfully deployed cilium without kube-proxy on the target new k8s cluster. Things are looking all ok in 'helmchartproxies' and 'helmreleaseproxies'. But there's nothing showing up in 'helm list' output for this cluster.

What did you expect to happen:
There should be output for cilium helm install in 'helm list' output.

Anything else you would like to add:
None

Environment:

• Cluster API version: v1.4.3
• Cluster API Add-on Provider for Helm version: Latest from git clone.
• minikube/kind version: Not using this. It is cluster built by BYOH cluster api provider.
• Kubernetes version: (use kubectl version): 1.27.3
• OS (e.g. from /etc/os-release): Debian Bullseye

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

User Story

As a [developer/user/operator] I would like to be able to change the version of the helm repository in a single HelmChartProxy depending on the version of the workload cluster.

Detailed Description

For some addons such as CNIs or cloud-controllers the version of the helm chart to use is dependent on the version of the workload cluster. These addons are also crucial for the operation of the workload cluster.

For example (versions are not the actual ones, but i hope it will make the problem clearer):

• For kubernetes 1.24.X calico might need to be installed using chart version 2.13.0
• For kubernetes 1.25.Y calico might need 2.14.0

Currently this can be done (afaik) only by creating 2 different HelmChartProxies and matching them to the k8s version (calico_1.24 using helm chart version 2.13.0 and calico_1.25 using helm chart version 2.14.0). The problem here is that when a cluster is upgraded from 1.24 -> 1.25:

• the HelmReleaseProxy mapping to calico_1.24 HCP will stop matching and calico 2.13.0 will be uninstalled
• the HelmReleaseProxy mapping to calico_1.25 will start matching and calico 2.14.0 will be installed
  (the order of installation/deletion can be different and it can cause different issues)

Completely uninstalling the CNI can be very problematic (similar for cloud-controllers). In reality, i just want CAAPH to be "smart enough" to just bump the chart version and run a helm upgrade, instead of uninstalling and reinstalling such a crucial addon.

Anything else you would like to add:

• I'm not sure what a good approach for this would be
• I'm also not sure whether I'm missing something and whether this can be achieved in a different way
• ValuesTemplate might also need to be different based on the k8s version but i think this is already doable with some formatting and using the .Cluster... variables

/kind feature

CAPI v1.7.0-beta.0 has been released and is ready for testing.
Looking forward to your feedback before v1.7.0 release!

For quick reference

• CAPI v1.7.0-beta.0 release notes
• Shortcut to CAPI git issues

Following are the planned dates for the upcoming releases

CAPI v1.7.0 will be released on Tuesday, 16th April 2024.

More details of the upcoming schedule can be seen at CAPI v1.7.0 release timeline.

User Story

As a user I would like to control behaviour of helm operations(Install, Upgrade, Delete, etc) via helm options like wait, skip-crds, timeout, waitForJobs, etc.

Detailed Description

As a user, if I want to see HelmChartProxy/HRP status deployed only when all pods are in Ready/Running state, this is not possible unless we specify wait=true option in install config.

We need to be able to define helm options in HelmChartProxy(which can be later propagated to HRP) like -

apiVersion: addons.cluster.x-k8s.io/v1alpha1
kind: HelmChartProxy
metadata:
  name: mychart
spec:
  clusterSelector:
    matchLabels:
      myChart: enabled
  repoURL: repo-url
  chartName: mychart
  options:
     wait: true
     timeout: 10m
     install: 
        noHooks: true
     upgrade:
        force: true

We can specify common options as a part of option and operation specific options in their corresponding fields like install, upgrade, etc. It'll also save us from hardcoding values in code.

Following are the options available with helm CLI, we can pick and choose the required ones and add support for those in HCP/HRP in phased manner.

Usage:
  helm install [NAME] [CHART] [flags]

Flags:
      --atomic                                     if set, the installation process deletes the installation on failure. The --wait flag will be set automatically if --atomic is used
      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle
      --cert-file string                           identify HTTPS client using this SSL certificate file
      --create-namespace                           create the release namespace if not present
      --dependency-update                          update dependencies if they are missing before installing the chart
      --description string                         add a custom description
      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored
      --disable-openapi-validation                 if set, the installation process will not validate rendered templates against the Kubernetes OpenAPI Schema
      --dry-run                                    simulate an install
  -g, --generate-name                              generate the name (and omit the NAME parameter)
  -h, --help                                       help for install
      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download
      --key-file string                            identify HTTPS client using this SSL key file
      --keyring string                             location of public keys used for verification (default "/Users/manoj.surudwad/.gnupg/pubring.gpg")
      --name-template string                       specify template used to name the release
      --no-hooks                                   prevent hooks from running during install
  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)
      --pass-credentials                           pass credentials to all domains
      --password string                            chart repository password where to locate the requested chart
      --post-renderer postRendererString           the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path
      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])
      --render-subchart-notes                      if set, render subchart notes along with the parent
      --replace                                    re-use the given name, only if that name is a deleted release which remains in the history. This is unsafe in production
      --repo string                                chart repository url where to locate the requested chart
      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
      --set-file stringArray                       set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2)
      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)
      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
      --skip-crds                                  if set, no CRDs will be installed. By default, CRDs are installed if not already present
      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)
      --username string                            chart repository username where to locate the requested chart
  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)
      --verify                                     verify the package before using it
      --version string                             specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used
      --wait                                       if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout
      --wait-for-jobs                              if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout

Usage:
  helm upgrade [RELEASE] [CHART] [flags]

Flags:
      --atomic                                     if set, upgrade process rolls back changes made in case of failed upgrade. The --wait flag will be set automatically if --atomic is used
      --ca-file string                             verify certificates of HTTPS-enabled servers using this CA bundle
      --cert-file string                           identify HTTPS client using this SSL certificate file
      --cleanup-on-fail                            allow deletion of new resources created in this upgrade when upgrade fails
      --create-namespace                           if --install is set, create the release namespace if not present
      --dependency-update                          update dependencies if they are missing before installing the chart
      --description string                         add a custom description
      --devel                                      use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored
      --disable-openapi-validation                 if set, the upgrade process will not validate rendered templates against the Kubernetes OpenAPI Schema
      --dry-run                                    simulate an upgrade
      --force                                      force resource updates through a replacement strategy
  -h, --help                                       help for upgrade
      --history-max int                            limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)
      --insecure-skip-tls-verify                   skip tls certificate checks for the chart download
  -i, --install                                    if a release by this name doesn't already exist, run an install
      --key-file string                            identify HTTPS client using this SSL key file
      --keyring string                             location of public keys used for verification (default "/Users/manoj.surudwad/.gnupg/pubring.gpg")
      --no-hooks                                   disable pre/post upgrade hooks
  -o, --output format                              prints the output in the specified format. Allowed values: table, json, yaml (default table)
      --pass-credentials                           pass credentials to all domains
      --password string                            chart repository password where to locate the requested chart
      --post-renderer postRendererString           the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path
      --post-renderer-args postRendererArgsSlice   an argument to the post-renderer (can specify multiple) (default [])
      --render-subchart-notes                      if set, render subchart notes along with the parent
      --repo string                                chart repository url where to locate the requested chart
      --reset-values                               when upgrading, reset the values to the ones built into the chart
      --reuse-values                               when upgrading, reuse the last release's values and merge in any overrides from the command line via --set and -f. If '--reset-values' is specified, this is ignored
      --set stringArray                            set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
      --set-file stringArray                       set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2)
      --set-json stringArray                       set JSON values on the command line (can specify multiple or separate values with commas: key1=jsonval1,key2=jsonval2)
      --set-string stringArray                     set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
      --skip-crds                                  if set, no CRDs will be installed when an upgrade is performed with install flag enabled. By default, CRDs are installed if not already present, when an upgrade is performed with install flag enabled
      --timeout duration                           time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)
      --username string                            chart repository username where to locate the requested chart
  -f, --values strings                             specify values in a YAML file or a URL (can specify multiple)
      --verify                                     verify the package before using it
      --version string                             specify a version constraint for the chart version to use. This constraint can be a specific tag (e.g. 1.1.1) or it may reference a valid range (e.g. ^2.0.0). If this is not specified, the latest version is used
      --wait                                       if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout
      --wait-for-jobs                              if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout

/kind feature

Which jobs are flaking:

On some CI runs for PRs, the TestReconcileForCluster spec is failing, but often succeeds on /retest.

Which tests are flaking:

TestReconcileForCluster/do_not_reconcile_for_a_paused_cluster

ok  	sigs.k8s.io/cluster-api-addon-provider-helm/controllers	9.075s
--- FAIL: TestReconcileForCluster (0.00s)
    --- FAIL: TestReconcileForCluster/do_not_reconcile_for_a_paused_cluster (0.00s)
        helmchartproxy_controller_phases_test.go:321: 
            Expected
                <bool>: true
            to be false
FAIL
FAIL	sigs.k8s.io/cluster-api-addon-provider-helm/controllers/helmchartproxy	0.114s
ok  	sigs.k8s.io/cluster-api-addon-provider-helm/controllers/helmreleaseproxy	0.055s
FAIL
make: *** [Makefile:395: test] Error 1

Testgrid link:

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_cluster-api-addon-provider-helm/203/pull-cluster-api-addon-provider-helm-test-main/1782485852740390912

Reason for failure (if possible):

?

Anything else we need to know:

• This test was added in #189 and has been flaky since it merged AFAICT.

/kind flake

User Story

As a operator I would like to be able to specify a local file path where my helm chart resides for deployment versus a URL so that I can maintain compliance with deployments in air-gapped or other environments where the addon being deployed needs to resolve to the local file path relative to execution.

Detailed Description

Enable a local file path option for the helm chart via RepoURL or alternative option.

apiVersion: addons.cluster.x-k8s.io/v1alpha1
kind: HelmChartProxy
metadata:
  name: nginx-ingress
spec:
  clusterSelector:
    matchLabels:
      nginxIngressChart: enabled
  repoURL: ./mychart
  chartName: nginx-ingress

/kind feature

User Story

I'd like to add additional test coverage beyond just the CAPI quick start and API version upgrade tests. These tests could validate that a Helm install of a chart is successful and deployed using the Helm Get() client, and that when we upgrade a chart, the revision is incremented or reinstalled if the release name/namespace changes. We could also validate the multi-cluster use case to verify that creating/deleting a new cluster with matching labels triggers the cluster selector.

/kind feature

We should set up some kind of validation in PRs similar to CAPI. To start, we can aim for something very basic like running a linter and ensuring that the code will compile.

In the future, we can set up some basic e2e testing in the code as well as GitHub to validate PRs before merging. This would likely involve spinning up a couple workload clusters and attempting to use HelmChartProxy to install a chart on few of them.

User Story

As a user, I would like to add metadata to the release namespace, as required by some charts [1]. A helm chart does not add metadata to the release namespace, for the same reason it does not create the release namespace.

[1] The speaker pod requires elevated permission in order to perform its network functionalities.
If you are using MetalLB with a kubernetes version that enforces pod security admission (which is beta in k8s 1.23), the namespace MetalLB is deployed to must be labelled...
-- https://metallb.org/installation/#installation-with-helm

Detailed Description

When CAAPH creates the release namespace, it should apply user-defined metadata (labels and annotations) to the namespace.

Anything else you would like to add:

Alternatives

1. Create the release namespace (with metadata) on the workload cluster, before creating the CAAPH resources for the release. If the cluster is based on a ClusterClass, this can be done using an AfterControlPlaneInitialized lifecycle hook.
2. Use a separate chart that creates a namespace, and then use that namespace as the release namespace.
3. Define a helm pre-install hook. This is a Kubernetes Job that helm creates before it creates the other resources in the release. The Job must create the namespace.

Implementation

CAAPH delegates namespace creation to the helm client. This client does not add metadata to the namespace, and helm maintainers have made it clear that this will not change. To be able to add metadata to the namespace, CAAPH would have to implement its own namespace creation.

/kind feature

User Story

We should add e2e tests for PRs in addition to unit tests so we can verify if a change or version bump will break the overall project. This same job can also be run periodically as well.
 
[Miscellaneous information that will assist in solving the issue.]

/kind feature

Can you help me understand why this reconciles on ClusterUnpaused OR ClusterControlPlaneInitialized and not on both of those (AND)? I've seen what looks like a race on move where I find multiple HelmReleaseProxies for the same HelmChartProxy and cluster - labels are set up correctly and created at same time (albeit at 1s fidelity from CreationTimestamp so can't tell which is created first).

I think that changing this logic to when a cluster is not paused AND the control plane has been initialized would solve this problem. I see that wouldn't work because the ClusterUnpaused explicitly requires the cluster to have previously been in unpaused state before to continue on update, which wouldn't be the case just following cluster control plane initialized.

From the move logs you can see the order that causes this issue:

Creating Cluster="self-hosted-18gxrd" Namespace="self-hosted-wokpvl"
...
Creating HelmChartProxy="cluster-autoscaler-self-hosted-18gxrd" Namespace="self-hosted-wokpvl"
...
Creating HelmReleaseProxy="cluster-autoscaler-self-hosted-18gxrd-7q6p4" Namespace="self-hosted-wokpvl"

By the time the HelmReleaseProxy has been moved, a new HelmReleaseProxy has already been created it seems.

What steps did you take and what happened:

Steps to reproduce

• Create Cluster A with clusterSelector(cluster.x-k8s.io/cluster-name: A) in namespace ns1
• Create Cluster A(same name) with clusterSelector(cluster.x-k8s.io/cluster-name: A) in namespace ns2

ubuntu@infra-bastion:~/jds$ k get cluster --show-labels -A
NAMESPACE                              NAME              PHASE          AGE     VERSION   LABELS
5c7792e2-0f2b-4fc8-b04a-3a7cf42b7460   ci-jds-cp-test    Provisioned    4h7m              cluster.x-k8s.io/cluster-name=ci-jds-cp-test
b5eb2819-5f6d-4a7c-b758-16da1be285cd   ci-jds-cp-test    Provisioned    155m              cluster.x-k8s.io/cluster-name=ci-jds-cp-test

• Create HCP A in namespace ns1
• Create HCP A(same name) in namespace ns2

ubuntu@infra-bastion:~/jds$ k get hcp -A
NAMESPACE                              NAME                       READY   REASON
5c7792e2-0f2b-4fc8-b04a-3a7cf42b7460   ci-jds-cp-test-ccm         False   HelmInstallOrUpgradeFailed @ HelmReleaseProxy/openstack-cloud-controller-manager-ci-jds-cp-test-r5jln
b5eb2819-5f6d-4a7c-b758-16da1be285cd   ci-jds-cp-test-ccm         True 

• HCP A creates HRP X for Cluster A in namespace ns1
• HCP A can't create HRP Y for Cluster A in namespace ns2

ubuntu@infra-bastion:~/jds$ k get hrp -A           
NAMESPACE                              NAME                                                       CLUSTER           READY   REASON                       STATUS            REVISION    
5c7792e2-0f2b-4fc8-b04a-3a7cf42b7460   openstack-cloud-controller-manager-ci-jds-cp-test-r5jln    ci-jds-cp-test    False   HelmInstallOrUpgradeFailed               

What did you expect to happen:

HCP A should create HRP Y for Cluster A in namespace ns2

Anything else you would like to add:

This is because the namespace of HCP is omitted when listing HRPs related to the HCP.

As a result, the addon can't be installed for Cluster A in namespace ns2

I already have a PR to fix this.

Environment:

• Cluster API version: v1.5.3
• Cluster API Add-on Provider for Helm version: v0.1.0-alpha.10
• minikube/kind version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug

Hi,
I'm newbie on clusterAPI operator and facing error log that appear continuously on caaph (addon-helm)
I'm testing clusterAPI with Openstack Infra that can provision workload cluster and using helmchartproxy for deploying cni (calico and cilium) for target workload
But, I see caaph pod report error log continuously about get kubeconfig for cluster

Below are logs that I collected about my facing:

1 helmreleaseproxy_controller.go:121] "Preparing to patch HelmReleaseProxy with return error" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="<namespace>/<name_of_helmreleaseproxy>" namespace="<namespace>" name="<name_of_helmreleaseproxy>" reconcileID="xxx-xxx-xxxx-xxx-xxx" helmReleaseProxy="<name_of_helmreleaseproxy>" reterr="failed to get kubeconfig for cluster: context \"default-context\" does not exist"
1 controller.go:329] "Reconciler error" err="failed to get kubeconfig for cluster: context \"default-context\" does not exist" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="<namespace>/<name_of_helmreleaseproxy>" namespace="<namespace>" name="<namespace>/<name_of_helmreleaseproxy>" reconcileID="xxx"
1 helmreleaseproxy_controller.go:121] "Preparing to patch HelmReleaseProxy with return error" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="<namespace>/<name_of_helmreleaseproxy>" namespace="<namespace>" name="<name_of_helmreleaseproxy>" reconcileID="xxx" helmReleaseProxy="<name_of_helmreleaseproxy>" reterr=null

These error logs have been appeared right after the first deployment of helmchartproxy on target workload cluster successfully. Seem they from result of func KubeconfigGetter.GetClusterKubeconfig but I not sure

Although I tested updating helm values via helmchartproxy of target workload cluster as well as check revision of helmreleaseproxy (with corresponding namespace) and configmap of target workload cluster, all still update successfully, I not sure how the above logs may affect helmchart 's lifecycle as well as values of cni on target workload cluster in future

Do I missing configure or we can ignore these logs at current? Thanks

Environment:

• Cluster API version: v1.6.0
• Cluster API Add-on Provider for Helm version: v0.1.1-alpha.1
• minikube/kind version: v1.6.0
• Kubernetes version: (use kubectl version): v1.28.4
• OS (e.g. from /etc/os-release): Ubuntu 20.04.4

/kind bug
/area logging

I would like to be able to set the LeaseDuration, RenewDeadline and RetryPeriod flags for the manager. These can be quite handy when the cluster runs on a relatively slow etcd and can mitigate multiple leaderElections being restarted due to slow etcd

/kind feature

What steps did you take and what happened:

I naively ran make test-e2e-local and it failed with an error that took a bit of investigation to fix:

DOCKER_BUILDKIT=1 docker build --build-arg builder_image=docker.io/library/golang:1.21.5 --build-arg goproxy=https://proxy.golang.org,direct --build-arg ARCH=arm64 --build-arg ldflags="-X 'sigs.k8s.io/cluster-api-addon-provider-helm/version.buildDate=2024-03-04T18:11:00Z' -X 'sigs.k8s.io/cluster-api-addon-provider-helm/version.gitCommit=a63ed8ffebda615e93f8f4c48a362b4a94746b5d' -X 'sigs.k8s.io/cluster-api-addon-provider-helm/version.gitTreeState=clean' -X 'sigs.k8s.io/cluster-api-addon-provider-helm/version.gitMajor=0' -X 'sigs.k8s.io/cluster-api-addon-provider-helm/version.gitMinor=1' -X 'sigs.k8s.io/cluster-api-addon-provider-helm/version.gitVersion=v0.1.1-alpha.1.11-a63ed8ffebda61' -X 'sigs.k8s.io/cluster-api-addon-provider-helm/version.gitReleaseCommit=ca44da536ee11b5ffd27f6f1a75f8a9552266caf'" . -t gcr.io//cluster-api-helm-controller-arm64:dev
[+] Building 0.0s (0/0)                                                                                        docker:desktop-linux
ERROR: invalid tag "gcr.io//cluster-api-helm-controller-arm64:dev": invalid reference format

What did you expect to happen:

Perhaps the Makefile could warn (or specific targets could error) if REGISTRY isn't set. Making this clear would help contributors figure out how to run the e2e tests locally.

/kind bug

/kind bug

[Before submitting an issue, have you checked the Troubleshooting Guide?]

What steps did you take and what happened:
[A clear and concise description of what the bug is.]
In a CI build with CAPZ 1.13, cloud-node-manager crashed because image tag is like this:

capzci.azurecr.io/azure-cloud-node-manager:%!s(float64=7.392922e+06)

I checked other logs, the actual image tag is 7392922.

I believe CAAPH didn't handle the tag as a string.

Actually, before CAAPH, the similar problem happens and we use helm --set-string

What did you expect to happen:
A number tag should be corrected parsed.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version: 1.13
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

What steps did you take and what happened:
Create a HelmChartProxy using e.g. https://docs.tigera.io/calico/latest/getting-started/kubernetes/helm#how-to

This results in the HelmChartProxy having a status of:

failed to create HelmReleaseProxy '' for cluster: clusters/test: HelmReleaseProxy.addons.cluster.x-k8s.io "projectcalico/tigera-operator-test-54fvf" is invalid: [metadata.generateName: Invalid value: "projectcalico/tigera-operator-test-": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*'), metadata.name: Invalid value: "projectcalico/tigera-operator-test-54fvf": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')]

What did you expect to happen:
Helm chart is applied to cluster.

Anything else you would like to add:
It looks like https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm/blob/main/controllers/helmchartproxy/helmchartproxy_controller_phases.go#L173 directly copies the name without sanitizing it for forbidden characters.

Environment:

• Cluster API version: 1.4.4
• Cluster API Add-on Provider for Helm version: v0.1.0-alpha.7
• minikube/kind version:
• Kubernetes version: (use kubectl version): v1.27.2
• OS (e.g. from /etc/os-release):

/kind bug

CAPI v1.6.0-beta.0 has been released and is ready for testing.
Looking forward to your feedback before v1.6.0 release!

For quick reference

• CAPI v1.6.0-beta.0 release notes
• Shortcut to CAPI git issues

Following are the planned dates for the upcoming releases

CAPI v1.6.0 will be released on Tuesday, 28th November 2023.

More details of the upcoming schedule can be seen at CAPI v1.6.0 release timeline.

User Story

There are several instances where we are using pointers for fields like HelmOptions.Install.CreateNamespace. This is because when it's set to nil, we want to default it to true. However, we can instead use kubebuilder tags to set that default field and no longer need a pointer. Moreover, removing the pointer type makes it show up by default when printing the CRD, as if HelmOptions is nil, the default value of CreateNamespace won't get set until Install is not nil.

/kind feature

When set up according to the development docs, CNI is not installed on the workload cluster.
https://github.com/kubernetes-sigs/cluster-api-addon-provider-helm/blob/main/docs/development.md

If CNI is not installed, the sample HelmChartProxy of nginx-ingress will not work, so I want to install CNI automatically.
Registering HelmChartProxy of calico as a Tilt resource, developers will no longer have to worry about CNI.

May I create a pull request for the above content?
I already created a HelmChartProxy manifest of calico and a shell script to register as a Tilt resource, and improved the document.

Note that I have worked together with @hiromu-a5a on this issue.

User Story

Move from alpha to beta API version, working towards GA stability with the addon provider.

/kind feature

What steps did you take and what happened:
Tried to deploy the new version
it gets images:

        image: registry.k8s.io/cluster-api-helm/cluster-api-helm-controller:v0.1.0-alpha.10

What did you expect to happen:
The controller to get deployed just fine

Anything else you would like to add:
From here i do not see the image being there: https://explore.ggcr.dev/?repo=registry.k8s.io%2Fcluster-api-helm%2Fcluster-api-helm-controller

Environment:

• Cluster API version:
• Cluster API Add-on Provider for Helm version:
• minikube/kind version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]