hcloud ccm fails if bool value is used for HCLOUD_NETWORK_ROUTES_ENABLED

[tcldr]

TL;DR

Currently, the hcloud ccm chart will fail to initialise if a boolean value is specified for the HCLOUD_NETWORK_ROUTES_ENABLED env var.

Expected behavior

The following config should work as expected:

HCLOUD_NETWORK_ROUTES_ENABLED:
    value: false # boolean rather than a string

Observed behavior

The pod fails to launch

Minimal working example

No response

Log output

Additional information

No response

[lukasmetzner]

Hey,

for the environment variables you can specify them with the value or valueFrom fields. To support this, we forward the whole YAML block to the Pod's env block and cannot make use of the Helm quote function. You have to quote the value yourself. Otherwise, the values type is interpreted as boolean, which conflicts with the Kubernetes spec that expects a string here. Here is some helpful documentation from Helm about using clear types: https://helm.sh/docs/chart_best_practices/values/#make-types-clear

To fix it, you only need to add quotes. This will ensure the type will only be interpreted as a string.

  HCLOUD_NETWORK_ROUTES_ENABLED:
    value: "false"

[tcldr]

Will do.

However, I think the linked documentation supports my point. The current implementation is confusing.

To support this, we forward the whole YAML block to the Pod's env block and cannot make use of the Helm quote function.

Perhaps this is the issue. Maybe the way env values are passed through can be updated so it's a little more robust?

[lukasmetzner]

We could improve the docstring to more clearly explain the behavior here.

That said, I don’t think we should perform any automatic type conversion. First, it breaks alignment with how Kubernetes handles environment variables in Pod specs, which can be surprising for users and lead to confusion when switching between our Helm chart and raw Kubernetes manifests. Second, it adds implicit logic that increases the maintenance burden and makes the behavior less transparent for both users and contributors. Finally, surfacing the original error encourages users to follow Kubernetes conventions directly, which promotes correct usage and avoids hidden issues down the line.

[github-actions[bot]]

This issue has been marked as stale because it has not had recent activity. The bot will close the issue if no further action occurs.