Terraform schemas for CUE

[roman-mazur]

Hello,

I wanted to share an experiment I conducted and see if I can get some feedback on it.

I have been using CUE to write Terraform configurations for quite a while. And I always was thinking that it would be nice to get the shemas of Terraform resources and data sources as CUE constrains in my code, so I can detect confiration mistakes a bit earlier.

Terraform does a fine job of validating its config, but it happens after it's exported from the code in CUE (when I execute terraform plan on the exported infra-config.tf.json).

This month I got some time to seriously approach the idea. Terraform has the providers schema -json command that generates a JSON document that describes what resources are exposed by the providers used in the Terraform config.
https://developer.hashicorp.com/terraform/cli/commands/providers/schema

This JSON document is not a JSON schema, but a bit like JSON schema. So I wrote some code that gets the schema for a particular Terraform provider, iterates over resource definitions there, transforms it to a JSON schema document (using CUE), and finally cue imports the generated JSON schemas, so that we get CUE definitions for the provider.

Here's an example of aws_instance (a Terraform resource that describes an EC2 instance):
https://github.com/roman-mazur/cuetf/blob/main/aws/res/aws_instance_gen.cue

Given AWS provider has ~2K different resources and data sources, I generated a lot of code in CUE.

Not all of the transformations succeeded though... I got some structure cycle errors which I will report separately, but a very big part of the AWS provider was imported this way. I also imported the Helm provider and 118 (out of 129) definitions of the Cloudflare provider.

Once I got the AWS definitions imported, I tried a very small example to see it in use.

package examples

import "rmazur.io/cuetf/aws"

awsServer: {
	aws.#Terraform & {
		provider: aws: region: "us-east-1"

		resource: {
			aws_instance: my_server: {
				ami:           "some-ami"
				instance_type: "t2.micro"
			}
		}
	}

	// Adding other resources.
	resource: null_resource: a_thing: {}
}

Doing cue export -e awsServer here gives the Terraform config. However, executing this command on my laptop takes ~15s.

$ time cue -e awsServer
...
cue export -e awsServer  16.19s user 0.84s system 132% cpu 12.890 total

Which brings us to the point that using the AWS provider schemas in CUE today is not practical :)
Getting feedback from terraform plan after cue export without these schemas will be much faster.

I wonder if this example can be a good target for the ongoing work in the performance optmization. My dream would be to have this under 1s. Let me know if this can be useful. Maybe it makes sense to add these defs to the Unity project?

Kind regards,
Roman

[roman-mazur]

One of the examples of errors I get in this experiment can be reproduced with the following script:

cd $(mktemp -d) && ( \
  set -e
  git clone https://github.com/roman-mazur/cuetf
  cd cuetf
  git checkout 24ffc1905717fd2b7c190248d0721555f5050a48
  cd internal/jsonschema/test/github && cue eval -e debug
)

This sample tries to convert terraform schema of a form

["list", ["object", {
  branch: "string"
  path:   "string"
  some_list: ["list", ["list", "string"]]
}]]

into a JSON schema (using the linked transformation). But fails to do it.

From what I understand, I run into some problem with recursive definitions, but I'm not sure how to resolve it.
If I change some_list here to have an item type that is different from what was used before (for example a primitive like string or a map), the transformation succeeds. For example, from

["list", ["object", {
  branch: "string"
  path:   "string"
  some_list: ["list", ["map", "string"]]
}]]

I get

{
        "type": "array",
        "items": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "branch": {
                    "type": "string"
                },
                "path": {
                    "type": "string"
                },
                "some_list": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "additionalProperties": {
                            "type": "string"
                        }
                    }
                }
            }
        }
    }

In the script to reproduce you change the cue invocation to have -t case=ok to see the successful scenario.

[roman-mazur]

Reported here: #3524