[Proposal] Templating bootstrap config

[jjsiv]

Hi,

I saw this issue recently in the control-plane repo: siderolabs/cluster-api-control-plane-provider-talos#230
and thought "yeah, that would be neat". Then I saw that a few years back variable support in config patches was already considered
#96

So I thought I could have a go at this and so have implemented some basic variables using go templates in my fork. It looks like this:

• we have 2 variables exposed by default - {{ .Cluster.Name }} and {{ .Machine.Name }} - of course, we could have more, such as {{ .Machine.ProviderID }} or {{ .Cluster.Version }}
• we have a way of defining custom variables, including sourcing them from secrets

An example configuration for TalosConfigTemplate:

spec:
  template:
    spec:
      generateType: worker
      talosVersion: v1.12.2
      variables:
      - name: supersecret
        valueFrom:
          secretKeyRef:
            name: somesecret
            key: somekey
      - name: disk
        value: /dev/sda
      strategicPatches:
        - |
          machine:
            network:
              hostname: {{ .Machine.Name }}
            install:
              image: factory.talos.dev/nocloud-installer/ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515:v1.12.2
              extraKernelArgs:
                - net.ifnames=0
              disk: {{ .Vars.disk }}
              wipe: true
            kubelet:
              extraConfig:
                serverTLSBootstrap: true
              extraArgs:
                cloud-provider: external
                rotate-server-certificates: true
            features:
              rbac: true
              kubePrism:
                enabled: true
                port: 7445
              hostDNS:
                enabled: true
                forwardKubeDNSToHost: true

I'm interested to see some opinions on this. Some things that I think should be considered still:

• templating engine - currently using text/template which I'm not convinced is ideal since it includes features such as control flow which I'm not exactly sure have a place here - perhaps we should stick to just variable expansions
• what other variables should we expose to the config?
• should we limit this to strategicPatches and data fields? should this work with configPatches as well?
• should there be a flag that explicitly enables templating of the configuration?

[bephinix]

Hi @jjsiv, your proposal sounds great to me. Here are my thoughts to your list:

• template engine: do you known how this is handled in other non-talos providers?
• variables: ProvideID and Version seem usefull; we can add more variables in further releases if anyone comes up with a use case
• I do not see any issues with allowing this for configPatches as well
• I would suggest to not use a flag

[jjsiv]

Thanks for the feedback.

Admittedly I have not looked much into other providers to see if they allow any form of templating (I know that kubeadm supports some variables for passing providerID to nodes), so perhaps that is something to look into. Though I must say I have warmed up a little bit to using text/template and maybe that is the way to go, especially that there does not seem to be an existing and actively maintained simple templating library. It also opens the possibility of using sprig if we wanted that.

As for configPatches, Talos has been moving towards multi-document configuration which is not supported by JSON patches, so we should probably keep in mind that this option might be getting deprecated and removed at some point in the future. Although until that happens I guess we might as well support templating there.

Either way, once I have some time I will prepare a PR and see where we go from there.

[bephinix]

Well, let us use text/template then as it is part of the standard library. This might lower maintenance work for the provider.

Regarding support for configPatches: I would suggest to check the complexity of implementing the template proposal. If the same few functions are just called with one or two additional maps, we should include it.

Feel free to mention me if you have pushed a PR for testing. 👍🏻

[knfoo]

This would be very useful for me as well.
In my use-case, I am using cluster-api-capm3 for bare-metal management.
For this the talos bootstrap provider should be able to lookup the infrastructureRef matching the machine, follow that ref and get the metaData secret name which contains values that I would want available in the template.
I will also be happy to test and help if needed.

[knfoo]

I have it running now based on the work in the siderolabs/cluster-api-control-plane-provider-talos#244. to get capi v1.12

I am not sure how to make it available as it requires both the bootstrap and the control-plane providers to be updated with the crd changes.

[Preisschild]

should we limit this to strategicPatches and data fields? should this work with configPatches as well?

With configpatches something like this should work, this wouldn't even require templating

configPatches:
- op: add
  path: /machine/registries/config/registry.example.org/auth/password
  valueFrom:
    secretKeyRef:
      name: somesecret
      key: somekey

[knfoo]

I might be reading this wrong: https://github.com/siderolabs/cluster-api-bootstrap-provider-talos?tab=readme-ov-file#configuration-patches
But is configPatches supported with multi-doc in Talos 1.12 and beyond ?

[Preisschild]

Yeah thats the problem with the configPatches.

Didn't know they aren't going to be supported at all in future talos versions.