is_known.md

page_title	subcategory	description
value_is_known Resource - terraform-provider-value		Allows you to have a access to result during plan phase that states whether value marked as "(known after apply)" or not. Provider Metadata Each module can use providermeta. Please keep in mind that these settings only count for resources of this module! (see https://www.terraform.io/internals/provider-meta https://www.terraform.io/internals/provider-meta): ```terraform // Terraform providermeta example terraform { // "value" is the provider name providermeta "value" { // {workdir} -> The only available placeholder currently (see below for more information) guidseed_addition = "{workdir}#for-example" // Results into "/path/to/workdir#for-example" } } ``` Optional guid_seed_addition (String) It serves as an guid seed addition to those resources that implement guid_seed as an attribute. But there are scopes you need to keep in mind: if guid_seed_addition has been specified in the provider block then top-level and nested modules are using the provider block seed addition. If guid_seed_addition has been specified in the providermeta block then only the resources of that module are using the module-level seed addition. Besides guid_seed, the provider block seed addition, the providermeta block seed addition and the resource type itself will become part of the final seed. Placeholders: "{workdir}" (Keyword) The actual workdir; equals to terraform's path.root. This placeholder is recommended because this value won't be dragged along the plan and apply phase in comparison to "abspath(path.root)" that you would add to resource seed where a change to path.root would be recognized just as usual from terraform.

value_is_known (Resource)

Allows you to have a access to result during plan phase that states whether value marked as "(known after apply)" or not.

Provider Metadata

Each module can use provider_meta. Please keep in mind that these settings only count for resources of this module! (see https://www.terraform.io/internals/provider-meta):

// Terraform provider_meta example
terraform {
	// "value" is the provider name
	provider_meta "value" {
		// {workdir} -> The only available placeholder currently (see below for more information)
		guid_seed_addition = "{workdir}#for-example" // Results into "/path/to/workdir#for-example"
	}
}

Optional

• guid_seed_addition (String) It serves as an guid seed addition to those resources that implement guid_seed as an attribute. But there are scopes you need to keep in mind: if guid_seed_addition has been specified in the provider block then top-level and nested modules are using the provider block seed addition. If guid_seed_addition has been specified in the provider_meta block then only the resources of that module are using the module-level seed addition. Besides guid_seed, the provider block seed addition, the provider_meta block seed addition and the resource type itself will become part of the final seed.

  Placeholders:

  • "{workdir}" (Keyword) The actual workdir; equals to terraform's path.root. This placeholder is recommended because this value won't be dragged along the plan and apply phase in comparison to "abspath(path.root)" that you would add to resource seed where a change to path.root would be recognized just as usual from terraform.

Schema

Required

• guid_seed (String) Attention! The seed is being used to determine resource uniqueness prior (first plan phase) and during apply phase (second plan phase). Very important to state is that the seed must be fully known during the plan phase, otherwise, an error is thrown. Within one terraform plan & apply the seed of every "value_is_known" must be unique! I really recommend you to use the provider configuration and/or provider_meta configuration to increase resource uniqueness. Besides guid_seed, the provider block seed addition, the provider_meta block seed addition and the resource type itself will become part of the final seed. Under certain circumstances you may face problems if you run terraform concurrenctly. If you do so, then I recommend you to pass-through a random value via a user (environment) variable that you then add to the seed.
• proposed_unknown (Dynamic) It is very crucial that this field is not filled by any custom value except the one produced by value_unknown_proposer (resource). This has the reason as its value is always unknown during the plan phase. On this behaviour this resource must rely and it cannot check if you do not so!
• value (Dynamic) The value (not nested attributes) is test against "(known after apply)"

Optional

• result (Boolean) States whether value is marked as "(known after apply)" or not. If value is an aggregate type, only the top level of the aggregate type is checked; elements and attributes are not checked.