How to stop terraform from zipping and encoding to base64 - ova user-data

Terraform Providers VMware
1

Hello,

I’m using ova templates in vSphere and I’ve been able to create a new template and inserting cloud-init works without any issues (describe here Format of cloudinit user-data variable in vsphere-clone - #3 by lethargosapatheia, in case it helps, but that’s not that important). So the cloud-init string for vApp needs to be base64 only and no compression, at least this is how I see it in the vSphere interface.

In terraform I’m doing this in a vsphere_virtual_machine block:

  clone {
    template_uuid = data.vsphere_virtual_machine.kubernetes_template.id
    customize {
      linux_options {
        host_name = "${each.key}"
        domain    = "company.internal"
      }

      network_interface {
        ipv4_address = "${each.value["ip_address"]}"
        ipv4_netmask = "24"
      }
      ipv4_gateway = "${var.gw}"
      dns_server_list = "${var.dns}"
    }
  }

  vapp {
    properties = {
        user-data = data.template_cloudinit_config.kubernetes["${each.key}"].rendered
    }
  }

So this is just a cloudinit template that normally (“normally” meaning with a classical template for guestinfo.userdata) works without issues, but terraform in the above code compresses everything (zips) and encodes it with base64 too. This is what I see directly also in the terraform state file.

This in turn results (somehow) into double encoding (for some reason) of base64 of a zipped string - this I can see in the vSphere interface (I manually decode it twice and unzip it). So I’ve no idea why terraform behaves differently from packer in this case, but the problem is that cloudinit simply ignores this, because it doesn’t identify anything and only the metadata (defined through linux_options, network_interface) works.

Any ideas why this is happening?

2

Refer to the documentation of the data source you are using, Terraform Registry, for options controlling this.

1 Like
3

Thanks :slight_smile: I was looking in the wrong part.

The VM still doesn’t identify the cloudconfig for some reason, but now the string seems correct at least.

It might be that cloudinit needs a different data source for the OVA templates. Maybe the OVF, I’ve no idea :slight_smile: I’ll have to look further.

4

Indeed, changing the cloud-init source to OVF worked :slight_smile:
For anyone else who might come across this, that means adding /etc/cloud/cloud.cfg.d/99-vmware.cfg with the following content:

datasource_list: [ OVF ]

This works with the OVA templates, which I’m using so that I can easily profit from ubuntu cloud images, reducing the template creating time by more 60-70% :slight_smile: (i.e. switching from vsphere-iso to vsphere-clone in packer)