If it's not set, schema/helper immediately returns an empty instance state with no id set, signalling that the resource does not yet exist.The provider implementation is then expected to call d.SetId(.) with a non-empty id if it detects that the resource already exists.
If it's set, call the Read implementation for the resource with a ResourceData whose id is empty and the attributes populated with the subset of the configuration that is non-computed.When Refresh is called with an empty id, helper/schema would check this flag and then: Helper/schema would then be altered so that the provider implementation can opt-in to being "pre-refreshed". If the returned, updated instance state has an id set, then we treat it as the resource already existing and return an error. With this approach, any time plan encounters a resource that does not yet exist in the state, it would call Refresh on that resource with an empty-string instance id. It is possible to implement something like the above UX with only minimal changes to the provider plugin interface by making use of the existing Refresh method. Implementation Ideas Lightweight Implementation It is less likely that an id derived from another Terraform-managed resource would be incorrect, but the this difference in behavior may be difficult to explain and justify to users. but that is not possible when either of them contain interpolations from resources that are not yet created. * aws_instance.foo: "t12.micro" is not a valid instance_type. The intent of the proposal is that the conflicting S3 bucket name would be caught during plan, so it would look like this from the user's perspective: It is impossible to completely prevent such issues, since the world continues to change around Terraform in the time period between plan and apply, but this proposal aims to reduce the likelihood of such errors by allowing resources to optionally perform a "pre-flight check" for a create diff. It is always frustrating when an error arises during apply, since it leaves the system in an incomplete state. When applying a config containing a new aws_s3_bucket instance, the plan stage will accept any syntactically-valid name, but when the plan is applied a dynamic error can be raised saying that the bucket name is in use. Several other AWS resources such as aws_db_instance require account-local or account-region-local identifiers to be provided by the user. A large number of resources within Terraform create objects that must have unique names, or other such constraints that can't be checked without calls to a backing API.įor example, aws_s3_bucket takes a name that must be globally-unique across the whole of AWS.
0 kommentar(er)
