terraform

Commit Graph

Author	SHA1	Message	Date
Paddy	890b006cc8	Delete terraform.tfstate Not sure why this got included.	6 years ago
Paddy Carver	546b58befc	First implementation of module attribution. A pass at implementing module attribution ("provider_meta blocks in the terraform block", whatever, it's for module attribution). The general idea is that we're adding a new ProviderMeta struct to our configs package, which is then added to Files, Modules, and parsed as part of the terraform block. The configs.Config type then makes that available to the terraform.ProviderTransformer type, which is already scoped by module. It picks out the ProviderMeta for the provider we need in its Transform method, and checks to see if the node it's working on implements the terraform.GraphNodeAttachProviderMetaConfigs interface, which is a new interface we're adding. It has only one method: AttachProviderMetaConfigs, which is passed a configs.ProviderMeta. We implement this on the terraform.NodeAbstractResource type, storing the passed configs.ProviderMeta in a new property on that struct. That struct is eventually made available to the terraform.NodeApplyableResourceInstance type, and its method evalTreeManagedResources, which creates an EvalApply type. The EvalApply type gets a ProviderMeta type, which is set to the *configs.ProviderMeta obtained from the terraform.NodeAbstractResource available to it. This means that EvalApply now has the raw config values the user entered for the provider_meta block, but we also need a schema; providers can define their own schema for the provider_meta block, and we need that schema to know how to translate what is in the config into a cty.Value, which is what we eventually want here. Fortunately, EvalApply already has access to the provider's schema; we can augment the GetSchema RPC call to pass back the ProviderMeta schema (added to helper/schema.Provider) in addition to resource, data source, and provider schemas. This makes it available, eventually, to EvalApply. Now that EvalApply has both the config values and the schema, we can parse them into a cty.Value. Finally, we augment the ApplyResourceChange RPC call with a ProviderMeta field, which can be populated by EvalApply with the parsed cty.Value, which successfully makes the config values available to the provider. This still needs tests written for it to ensure it works, but no current tests are broken on it and it compiles, which is reassuring.	6 years ago
Radek Simko	5b9f2fafc8	Standardise directory name for test data	7 years ago

Author

SHA1

Message

Date

Paddy

890b006cc8

Delete terraform.tfstate

Not sure why this got included.

Paddy Carver

546b58befc

First implementation of module attribution.

A pass at implementing module attribution ("provider_meta blocks in the
terraform block", whatever, it's for module attribution).

The general idea is that we're adding a new ProviderMeta struct to our
configs package, which is then added to Files, Modules, and parsed as
part of the terraform block.

The configs.Config type then makes that available to the
terraform.ProviderTransformer type, which is already scoped by module.
It picks out the ProviderMeta for the provider we need in its Transform
method, and checks to see if the node it's working on implements the
terraform.GraphNodeAttachProviderMetaConfigs interface, which is a new
interface we're adding. It has only one method:
AttachProviderMetaConfigs, which is passed a *configs.ProviderMeta.

We implement this on the terraform.NodeAbstractResource type, storing
the passed *configs.ProviderMeta in a new property on that struct.

That struct is eventually made available to the
terraform.NodeApplyableResourceInstance type, and its method
evalTreeManagedResources, which creates an EvalApply type.

The EvalApply type gets a ProviderMeta type, which is set to the
*configs.ProviderMeta obtained from the terraform.NodeAbstractResource
available to it.

This means that EvalApply now has the raw config values the user entered
for the provider_meta block, but we also need a schema; providers can
define their own schema for the provider_meta block, and we need that
schema to know how to translate what is in the config into a cty.Value,
which is what we eventually want here.

Fortunately, EvalApply already has access to the provider's schema; we
can augment the GetSchema RPC call to pass back the ProviderMeta schema
(added to helper/schema.Provider) in addition to resource, data source,
and provider schemas. This makes it available, eventually, to EvalApply.

Now that EvalApply has both the config values and the schema, we can
parse them into a cty.Value.

Finally, we augment the ApplyResourceChange RPC call with a ProviderMeta
field, which can be populated by EvalApply with the parsed cty.Value,
which successfully makes the config values available to the provider.

This still needs tests written for it to ensure it works, but no current
tests are broken on it and it compiles, which is reassuring.

Radek Simko

5b9f2fafc8

Standardise directory name for test data

3 Commits (paddy_module_attribution_tmp)