A method for providers to influence import config generation

[jbardin]

When generating configuration during the import process, Terraform can only guess what portion of the imported state should be used as configuration. There many cases where optional+computed fields are validated differently depending on whether they originate from configuration or the provider, but Terraform has no way to determine if the value should be included in the config.

The most obvious example is where legacy SDK marks all id attributes as optional+computed even though they can never be included in the configuration, so Terraform must unilaterally remove them from generated config even though a new provider could technically allow that field.

In order to solve this we need a new mechanism for the provider to communicate which fields from the state should be used for configuration. This may be related to the possible addition of an import schema, which could relay more structured information to the provider for import instead of a single import id string.

[bt-macole]

this relates to #33427. I was imagining a world where dynamic (optional) import blocks could be auto generated based on provider schemas.

[apparentlymart]

When we discussed this before I remember another option we considered was a provider function that takes an object of the form that we'd normally track as "current state" (everything populated, no unknowns) and returns the kind of object we'd normally pass to ValidateResourceConfig or as the configuration object in PlanResourceChange, except that unknown values are not allowed because the input has no unknowns itself.

That would then essentially ask the provider "what is the canonical way to represent this given state in the configuration?" and the provider can choose to discard any part of the input as something that needn't be included in the configuration, as long as the result is still valid according to the schema and the provider's own validation rules.

This is a design with the provider running arbitrary code when requested, rather than a declarative design based on schema, so it'd give provider developers the most flexibility but it also implies that we can only run this operation in contexts where it's acceptable to start up a provider plugin, and not in contexts which rely only on schema snapshots captured earlier.

We'll need to weigh these trade-offs as part of designing a solution here.

[KylePeterDavies]

@jbardin @apparentlymart is this on the backlog? Without this the code generation will never work properly.

[apparentlymart]

Hi @KylePeterDavies,

I no longer work on Terraform at HashiCorp, so I don't know what the Terraform team's plans are for this issue.