Comment 4 for bug 1884071

@Bryan

> I don't see how it'd be possible to submit gzip binary data with hetzner
> cloud as user-data since the user-data field expects a string on hetzner
> cloud. This means the only way to provide user-data is with
> base64encoding.

cloud-init treats the user-data content as binary. If the platform does
not allow you to put binary data there, then there isn't much we can do.

In the case of "gzip"ed data, cloud-init attempts to transparently
uncompress it. But otherwise, without explicit instruction, cloud-init
does not modify the data.

> I assumed since other providers with cloud-init allow base64 this would
> be the way it would work here as well. Cloud-init is a singular

Other providers like EC2 actually provide the consumer (cloud-init) with
binary data. They just require base64 encoding when posting to their API
server. But they *always* require base64, and *always* provide binary to
cloud-init. So there is no guessing.

> separately maintained project included with the OS, so I'd expect the
> base64 handling be a standard feature handled from within the
> application itself not something the cloud provider would maintain or
> add on their own.

> Even the terraform modules for templating cloud init hard depend base64
> encoding on enabling gzip compression:

> Error: base64_encode is mandatory when gzip is enabled

> on main.tf line 1, in data "cloudinit_config" "user_data":
> 1: data "cloudinit_config" "user_data" {

> I tried changing my mime type to use text/cloud-config-archive instead
> of text/cloud-config with the same result.

If you submit user-data to the API, and then cloud-init correctly
gets the cloud-config-archive, then it should work.

If you have submitted such data, please run 'cloud-init collect-logs' and
attach the output.