Cilium Value Override

[EssamEmad]

TL;DR

There's no easy way to override Cilium values without boilerplate. Should we add cilium_values_override to variables.tf?

Problem

Hello! Thanks for the great library!
The library provisions Talos in an opinionated way where it uses Cilium as a default CNI. This is good as Cilium provides a lot of benefits to a K8s cluster. However, when trying to extend Cilium further, boilerplate unnecessarily increases because the library either uses the default or drop the defaults in favour of user-generated cilium values. Is there an easy way to provide a single override (something like gatewayAPI.enabled = true)?

Proposition

If there isn't, does it make sense to add something like cilium_overrides which get merged with the cilium_defaults? If this looks like a reasonable direction, I can send a PR.

[mrclrchtr]

Hi, thanks for reaching out.

I'm using the values file of the cilium helm chart, to overwrite the default values and use the exact values, that gets deployed by ArgoCD later:

cilium_values = [templatefile("../../../core/kube-system/cilium/values.yaml", {})]

But yes, I think the possibility to override would be a nice enhancement.

You are welcome to do a PR.

[EssamEmad]

I created PR #281 that addresses the underlying issue behind this issue. I added context in the PR. Could you take a look please?

Thanks

[mrclrchtr]

Thanks for the PR. I've done a review and added some comments.

[ividrine]

Yeah it looks like currently its not possible to use this module with Cilium Gateway API enabled since the Gateway API CRDs have to be pre installed according to docs. I think there would be a lot of value in adding support for this.

[hsudbrock]

Hi; also thanks for the great library :)

I stumbled over this issue when installing the tailscale operator in my cluster. This operator requires a special cilium setting for bypassing the socket LB in pods, and it would be helpful to override this single cilium setting.

I read above that #281 addresses the issue underlying this issue; but, if I am not mistaken, #281 will not permit to override single cilium settings (but instead focuses on cilium gateway api).

Would you still be interested in a change that tackles the original intent of this issue, adding a cilium_overrides variable? Or would this no longer be needed with #281, and I just missed something?

[mrclrchtr]

Yes you are right: To be clear: PR #281 solves a different problem. It adds Gateway API support as a feature toggle (cilium_enable_gateway_api), but doesn't solve the general override mechanism you're asking for here.

The current approach forces users to choose:

• Module defaults → no customization beyond a few cilium_enable_* flags
• cilium_values → must duplicate all module defaults manually

This doesn't scale. Every new Cilium feature would need another boolean variable, and you still can't override arbitrary nested values (like your Tailscale operator socket LB bypass use case).

I will implement a suitable variable "cilium_overrides" that supports deep integration with the module's default settings to fix this issue in the short term.

Once again regarding Cilium. I decided to use it at the time because I thought it was better than flanel. However, I now feel that I have created too much dependency, which requires more attention than the module itself. I am considering removing it to eliminate the support effort. After bootstrap, everyone can still switch to cilium themselves.

[hsudbrock]

Thanks a lot for the helpful response,, @mrclrchtr!

I will implement a suitable variable "cilium_overrides" that supports deep integration with the module's default settings to fix this issue in the short term.

Also thanks for this! If you think it could make things easier for you if I provided a pull request for the cilium_overrides, I could also do that. (Not sure though what you refer to with deep integration - what I had thought of was simply the possibility to override any of the settings provided by the cilium helm chart.)