(going to use this chat to work in public more often 🙂 )

Do they have a Terraform plan JSON or state JSON? We support both assuming they are generated from Terraform v0.12+. If so, it really depends on how much they change it. Do they want to know the specific keys we use inside the file?

@eager-accountant-5294 I think the issue is that depending on the resource, the set of information required is different. E.g. azurerm_linux_virtual_machine has its own set of params that is different to aws_instance.

@little-author-61621 we butcher the JSON so much, it’s not usable as direct input into infracost. So, we need to know what format to generate ourselves. We’ll generate it like any other JSON. So we need to know the structure you expect, the fields needed per resource, etc. We can easily read this from the code, but I couldn’t find it in the GH repo.

Hi @eager-accountant-5294. There's a few things we use from the plan JSON in https://github.com/infracost/infracost/blob/master/internal/providers/terraform/parser.go, but I think the main things are: *

configuration.provider_config

to try and work out the regions * `planned_values > ... resources > {address,type,values}`to build a list of resources, but the values we actually need are specified per resource. * and

configuration > ... resources > expressions

to build references between resources For each resource, we don't have a set schema yet but you can find the values that we need by running something like this:

grep -rnw 'internal/providers/terraform' -e 'd.Get\(([^)]*)\)'

It will give you output like this:

internal/providers/terraform/azure/notification_hub_namespace.go:25:	if d.Get("sku_name").Type != gjson.Null {
internal/providers/terraform/azure/notification_hub_namespace.go:26:		sku = d.Get("sku_name").String()
internal/providers/terraform/azure/linux_virtual_machine.go:26:	instanceType := d.Get("size").String()
internal/providers/terraform/azure/linux_virtual_machine.go:30:	if d.Get("additional_capabilities.0.ultra_ssd_enabled").Bool() {
internal/providers/terraform/azure/app_service_environment.go:27:	if d.Get("pricing_tier").Type != gjson.Null {
internal/providers/terraform/azure/app_service_environment.go:28:		tier = d.Get("pricing_tier").String()

everything inside the

d.Get()

call is a path within the

values

object for the resource. Then we also use some other values for building the references, which you can get from the

ReferenceAttributes

property of each resource, e.g.: https://github.com/infracost/infracost/blob/master/internal/providers/terraform/aws/elasticache_cluster.go#L16.

It seems like after parsing the TF plan, there is a struct defining the Project and its Resources. That gets queried against a graphql API. Shouldn’t we simply work directly with the graphql API?

It seems like after parsing the TF plan, there is a struct defining the Project and its Resources.

Yep, the problem with querying the graphql API directly is that all the mappings from the terraform resources are in the CLI. Is it possible to create a plan that includes those

d.Get()

values?

Possible - yes. It’s just weird so trying to find a better path 🙂 What’s in the graphql API?

At the moment it's pretty much just the same as the AWS Bulk Pricing API, but also with some spot prices. So there's not any logic around mapping resources to prices there yet. We haven't concentrated on that part too much yet.

This is the part that I thought longer term you can link into

Got it. So the best path is to generate a TF-json ourselves that’s compatible with what the CLI parses and call the CLI.

At the moment yes. We're working on refactoring the resources to be more structured so they work with different IaC tools, so this might help longer term, so would be interested to get your feedback on it. The idea is that we'll extract the IaC fields into a standard struct for each resource type. You can see an example here: https://github.com/infracost/infracost/blob/master/internal/resources/aws/dynamodb_table.go#L9-L24.

Yeah that would make a LOT of sense. For example, we support TF today, soon CFN, then Pulumi, so in most cases we won’t even be coming from TF as a source.