I’m trying to launch some containers with Terraform, which has a nifty provider including a function called cloudinit_config, which “renders a multipart MIME configuration for use with cloud-init”. The thing about this function is that it only allows you do enable gzip if you also enable base64_encode, and from my testing it seems like the strings that are produced by this are not actually parsed by cloud-init.
I tried taking the encoded string from Terraform and launching a container with it like so:
$ lxc launch ubuntu:jammy hostname --config=cloud-init.user-data="H4sIAAAAAAAA(...)"
When I check cloud-init.log I think this means that it was at least received:
DataSourceLXD.py[DEBUG]: [GET] [HTTP:200] http://lxd/1.0/config/cloud-init.user-data
util.py[DEBUG]: Writing to /var/lib/cloud/instances/0ce1cb92-1b0b-49bf-8411-04b5ec8030d1/user-data.txt - wb: [600] 564 bytes
util.py[DEBUG]: Writing to /var/lib/cloud/instances/0ce1cb92-1b0b-49bf-8411-04b5ec8030d1/user-data.txt.i - wb: [600] 872 bytes
When I look at those files, I can see that:
user-data.txtcontains the encoded stringuser-data.txt.ilooks like this:
Content-Type: multipart/mixed; boundary="===============7769463438994593384=="
MIME-Version: 1.0
Number-Attachments: 1
--===============7769463438994593384==
MIME-Version: 1.0
Content-Type: text/x-not-multipart
Content-Disposition: attachment; filename="part-001"
H4sIAAAAAAAA/(... same base 64 encoding ...)
--===============7769463438994593384==--
I’m guessing that this is actually an issue with cloud-init, but I’m just asking for guidance here if this is expected to work – for example if there’s a way to configure cloud-init to look for this type of string – or whether this is just a weird way to do it that is not supposed to work locally, but is targeted towards cloud provider APIs where the base64 encoding is required to transfer the data as text.
Can I get it to work, or should I just give up and pass in plaintext instead?