Ignition fails to detect cloud-config when jinja templates are used

[hrak]

Description

Ignition's isCloudConfig function doesn't properly detect cloud-config when using jinja templates. For example, Kubernetes cluster-api uses jinja templates for cloud-config. The user-data fetched from metadata service looks like this (gzipped):

## template: jinja
#cloud-config

write_files:
-   path: /etc/kubernetes/pki/ca.crt
    owner: root:root
    permissions: '0640'
    content: |
      -----BEGIN CERTIFICATE-----
      <snip snip>
      -----END CERTIFICATE-----
      etc. etc.

The isCloudConfig function only looks for the first line of the config to contain #cloud-config:

func isCloudConfig(userdata []byte) bool {
	header := strings.SplitN(string(decompressIfGzipped(userdata)), "\n", 2)[0]

	// Trim trailing whitespaces
	header = strings.TrimRightFunc(header, unicode.IsSpace)

	return (header == "#cloud-config")
}

But in the case of Jinja templates, the first header is ## template: jinja. The function isCloudConfig will have to be adapted to check in at least the first 2 lines for #cloud-config.

Impact

cloud-config is not detected, resulting in config.Parse attempting to handle the user-data as raw json, which it isn't (its gzipped yaml), resulting in a boot failure and emergency mode

Environment and steps to reproduce

1. Set-up:
   flatcar-stable-3374.2.3 running in Cloudstack (KVM virt)
2. Task: booting a control plane node using Kubernetes cluster-api
3. Action(s):
   a. boot an instance with user-data containing a cloud-config using jinja templates
4. Error: see above

Expected behavior

Proper boot and processing of cloud-config

Additional information

Please add any information here that does not fit the above format.

[pothos]

Thanks for reporting, that's something we need to fix upstream but could already backport it, maybe to Flatcar Alpha/Beta if not Stable

[jepio]

I see where you're coming from but there are a couple of issues getting mixed up here:

• the way cluster-api works with Flatcar is you need to pass format: ignition (https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/templates/cluster-template-flatcar.yaml#L61-L62). This is the relevant file https://github.com/kubernetes-sigs/cluster-api/blob/5c6fb4bc89efb6325852392e8369ba6aa767881b/bootstrap/kubeadm/internal/ignition/ignition.go
• coreos-cloudinit, which is the only cloudinit that works on flatcar, does not support jinja templates (because it is not implemented in python)

So this is not something that will work, even if ignition accepts it.

[pothos]

Ah right, coreos-cloudinit couldn't handle it anyway^^ So unless running the real cloud-init on Flatcar is a thing, we don't need this for Flatcar. (Still it would be nice to fix the detection.)

[hrak]

I see where you're coming from but there are a couple of issues getting mixed up here:

* the way cluster-api works with Flatcar is you need to pass `format: ignition` (https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/templates/cluster-template-flatcar.yaml#L61-L62). This is the relevant file https://github.com/kubernetes-sigs/cluster-api/blob/5c6fb4bc89efb6325852392e8369ba6aa767881b/bootstrap/kubeadm/internal/ignition/ignition.go

* coreos-cloudinit, which is the only cloudinit that works on flatcar, does not support jinja templates (because it is not implemented in python)

So this is not something that will work, even if ignition accepts it.

Aah, thanks for pointing that out. I will try ignition instead!

Fixing the detection might indeed be nice, though if it results in a broken cloud-config it might not be that useful. Maybe throw an error to indicate that jinja is unsupported?