Version v0.2 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot. For up-to-date documentation, see the latest version.
Server resources can be updated by using the
configPatches section of the custom resource.
Any field of the Talos machine config
can be overridden on a per-machine basis using this method.
The format of these patches is based on JSON 6902 that you may be used to in tools like kustomize.
Any patches specified in the server resource are processed by the Metal Metadata Server before it returns a Talos machine config for a given server at boot time.
A set of patches may look like this:
apiVersion: metal.sidero.dev/v1alpha1 kind: Server metadata: name: 00000000-0000-0000-0000-d05099d33360 spec: configPatches: - op: replace path: /machine/install value: disk: /dev/sda - op: replace path: /cluster/network/cni value: name: "custom" urls: - "http://192.168.1.199/assets/cilium.yaml"
Testing Configuration Patches
While developing config patches it is usually convenient to test generated config with patches before actual server is provisioned with the config.
This can be achieved by querying the metadata server endpoint directly:
$ curl http://$PUBLIC_IP:9091/configdata?uuid=$SERVER_UUID version: v1alpha1 ...
$PUBLIC_IP with the Sidero IP address and
$SERVER_UUID with the name of the
Server to test
If metadata endpoint returns an error on applying JSON patches, make sure config subtree being patched exists in the config.
If it doesn’t exist, create it with the
op: add above the
op: replace patch.
Combining Patches from Multiple Sources
Config patches might be combined from multiple sources (
ServerClass), which is explained in details
in Metadata section.