Set upper case label keys and values on google_compute_instance

Am trying to set labels on Google cloud instances that are upper case and include special characters like “.” and “:”. Since this is a port of an existing application from AWS changing semantics of the labels is not a possibility.

I explored the possibility of using base32 encoding to get around this (base64 does not work because it is mixed case which does not work with GCP labels). There is an open pull request for terraform to have base32 support (introduces base32 related encoding functions with documentation by ufukty · Pull Request #29127 · hashicorp/terraform · GitHub) but that has not been merged.

Given the lack of a base32 function in terraform, I was hoping I could get terraform to preprocess + expand + interpolate my files and write them out as fully expanded terraform files, which I can then postprocess using a script to base32 encode the labels before I do terraform plan/apply on the results. Want to know if there is a way to get preprocessed output out of terraform - especially where constructs like the for-each and count have been expanded away ?

Hi @deepankarsharma,

Terraform doesn’t have a separate “preprocessing” step and instead the expressions in your configuration are gradually evaluated as a core part of the plan and apply process. In some cases a value might not be known until some other action was taken during the apply phase, so there isn’t any sense of an “expanded configuration” that already has all of the results in it.

However, what you can do in principle is apply the configuration somewhere (e.g. a development environment) and then run terraform show -json to get a machine-readable description of the latest state snapshot, which is the closest equivalent to an expanded version of the configuration: the configuration describes a desired state which Terraform only learns during the plan and apply process, whereas the state captures the actual results of applying that desired state and so it will always have constant values, with any dynamic expressions from the configuration already evaluated.

Thanks for the prompt response @apparentlymart. I will give this a try.