Potential improvement for `import {}` block

Terraform
1

Just been using the new import {} block and I think there could be a useful change to reduce the volume of content in the new resource block.

As many resources have a LOT of properties, it is not unusual for the default values for the properties to be an empty string (""). If the property is numeric or boolean, the default values for them may be 0 or false.

Having the generated resource contain documentation of some manner to inform the developer that the values are default values will certainly help.

I’ve got 3 suggestions:

  1. A comment after each property
    resource "cloud_imported" {
 id        = "the_id"
 property1 = ""    // Default value
 property2 = 0     // Default value
 property3 = false // Default value
 property4 = "value"
}
  2. Grouped at the end of the block
    resource "cloud_imported" {
 id        = "the_id"
 property4 = "value"

 // Default values
 property1 = ""
 property2 = 0
 property3 = false
}
  3. Just don’t bother putting them in at all, as they are default!
    resource "cloud_imported" {
 id        = "the_id"
 property4 = "value"
}

The one area that is of concern is where an empty string, or 0, or false is NOT the default value and so presenting a LOT of them next to each other, with no distinguishing marker, doesn’t trigger anything that may be of concern to a developer.

Yes, I know, at the plan, the property with what looked like a default value being removed will trigger a change and the plan will say something, but for the sake of 1 additional output in the resource block, the plan wouldn’t have been needed.

As the default values are already known to the provider, having the current values compared to the default values and that comparison being presented meaningfully will help a LOT of people know what the real values are.

My overall preference would be example 3, but that may not always be enough. Splitting the default values away like example 2 would probably be the most useful over all.

2

Hi @rquadling,

Thanks for the feedback!
What you’re asking for isn’t possible yet, since Terraform does not have any of this information. We can only take the state returned by the provider, and try to fashion that into something that might work as a configuration by removing computed attributes.

There is an open issue about the general problem in A method for providers to influence import config generation · Issue #33438 · hashicorp/terraform · GitHub. This also fits into larger issues about accepting structured data for the import process, and how to deal with required attributes which cannot be returned by the provider at all. We have plans to try and address these issues, but they will require changes to the providers and the protocol, so will take significantly more time to get into production.

1 Like