As it says in the title, when terraform generates a config file from an existing entity, it always fails when there are validation conflicts. For example, if two attributes are marked in the schema as conflicting with each other, the generation will always fail out. It DOES generate the file, but it should be able to figure out that empty attributes should be left out. Alternatively, terraform should treat empty values as not existing for purposes of ConflictsWith and other validators (such as ExactlyOneOf)
Hi @craig.west,
The only way Terraform has to generate the configuration is to structure the state returned by the provider into a structure representing the configuration. Terraform does not know anything about validations done by the provider, only what is the value of the state data. The generated config often requires manual editing, primarily because there’s no way to infer references from the configuration, but the fact that it can’t complete the plan successfully is unfortunate.
There are a number of resources around that can’t have config generated automatically for various similar reasons. The solution is going to take a bit of work however, since it will require a new protocol for config generation, and providers to implement the config generation for the resources which are not handled automatically.
Isn’t it terraform plan which is doing the generation? That SHOULD have some knowledge of conflicting resources, as it is at the plan stage where those conflicts show up
This problem will come up with all resources with attributes which should not be all defined simultaneously. In the SDK this would be ConflictsWith, ExactlyOneOf, etc, the framework has similar constructions
Yes, Terraform is generating the config during the plan, but the problem here is that Terraform doesn’t have the information necessary to do any more than guess at what the configuration should look like. Any constraints on what parts of the state can appear in the configuration are external, and live only in the provider, but there is no interface for the provider
Config generation right now is only meant as a starting point, which is why it’s still labeled “Experimental” and requires an explicit flag on the CLI. It will require the development of additional features to allow the provider to assist in creating a more precise configuration.