Unable to adjust log level

[networkhell]

What steps did you take and what happened: With default setting all helm values are logged during every reconciliation loop like

I0324 13:42:57.081220       1 helm_client.go:327] "Located chart at path" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="mgmt-dev-wavestack-muc5/openstack-cloud-controller-manager-mgmt-dev-257kc" namespace="mgmt-dev-wavestack-muc5" name="openstack-cloud-controller-manager-mgmt-dev-257kc" reconcileID="7c5544cb-6f20-463d-b81a-dc5fbc16a858" path="/tmp/xdg/.cache/helm/repository/openstack-cloud-controller-manager-2.31.3.tgz"
I0324 13:42:57.081244       1 helm_client.go:329] "Writing values to file" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="mgmt-dev-wavestack-muc5/openstack-cloud-controller-manager-mgmt-dev-257kc" namespace="mgmt-dev-wavestack-muc5" name="openstack-cloud-controller-manager-mgmt-dev-257kc" reconcileID="7c5544cb-6f20-463d-b81a-dc5fbc16a858"
I0324 13:42:57.081255       1 helm_client.go:385] "Writing values to file" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="mgmt-dev-wavestack-muc5/openstack-cloud-controller-manager-mgmt-dev-257kc" namespace="mgmt-dev-wavestack-muc5" name="openstack-cloud-controller-manager-mgmt-dev-257kc" reconcileID="7c5544cb-6f20-463d-b81a-dc5fbc16a858"
I0324 13:42:57.081310       1 helm_client.go:342] "Values written to file" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="mgmt-dev-wavestack-muc5/openstack-cloud-controller-manager-mgmt-dev-257kc" namespace="mgmt-dev-wavestack-muc5" name="openstack-cloud-controller-manager-mgmt-dev-257kc" reconcileID="7c5544cb-6f20-463d-b81a-dc5fbc16a858" path="/tmp/openstack-cloud-controller-manager-mgmt-dev-openstack-cloud-controller-manager-584839087.yaml"
I0324 13:42:57.081345       1 helm_client.go:348] Values written to file /tmp/openstack-cloud-controller-manager-mgmt-dev-openstack-cloud-controller-manager-584839087.yaml are:
cloudConfig:
  global:
    auth-url: ***
    application-credential-id: "***"
    application-credential-secret: "***"
  loadBalancer:
    floating-network-id: ***
    create-monitor: true

I0324 13:42:57.082799       1 helm_client.go:415] Diff between values is:
I0324 13:42:57.083214       1 helm_client.go:371] "Release `mgmt-dev-openstack-cloud-controller-manager` is up to date, no upgrade required, revision = 2" controller="helmreleaseproxy" controllerGroup="addons.cluster.x-k8s.io" controllerKind="HelmReleaseProxy" HelmReleaseProxy="mgmt-dev-wavestack-muc5/openstack-cloud-controller-manager-mgmt-dev-257kc" namespace="mgmt-dev-wavestack-muc5" name="openstack-cloud-controller-manager-mgmt-dev-257kc" reconcileID="7c5544cb-6f20-463d-b81a-dc5fbc16a858"

What did you expect to happen: I need to be able to configure that helm values are not logged at all to prevent secrets being forwarded to log aggregation.

Anything else you would like to add: Maybe this is not an issue. But I did not find any information regarding adjusting the log level in the docs. Neither I was able to find any useful information within the code (with very limited go knowledge).

Environment:

• Cluster API version: v1.9.5
• Cluster API Add-on Provider for Helm version: v0.3.1
• minikube/kind version: -
• Kubernetes version: (use kubectl version): 1.31.7
• OS (e.g. from /etc/os-release): flatcar 4081.3.2

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

[Jont828]

This is likely the line that you're looking for, it sets the verbosity level to 2. Removing it should change the log level to 0. I'll need to look into if CAPI has a better way of configuring this.

[networkhell]

Thanks for the hint how to workaround this. In the meantime I shifted my application credentials from helm values to a secret deployed with a ClusterResoureSet. But it may be helpful to be able to easily adjust the controllers log level :-)

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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-sigs/prow repository.