CAAPH report log context "default-context" does not exist while preparing to patch HelmReleaseProxy

[phuongvtn]

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

[k8s-ci-robot]

@phuongvtn: The label(s) area/logging cannot be applied, because the repository doesn't have them.

In response to this:

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Jont828]

@phuongvtn I believe the kubeconfig logic was changed in #248. Could you try to see if you're still having the same issue?