When upgrading to the newest provider or Terraform version, I often need to correct my configs to use the new syntax and change deprecated features. Examples:
Interpolation-only expressions are deprecated in 0.12
The aws_lb_listener_rule in the AWS provider was updated to allow for a different (and better! thank you!) way of specifying conditions.
When I change my Terraform projects to use a new version of the provider or Terraform itself, it would be really helpful to see all warnings, even if there are dozens of them, so that I can correct them quickly. Right now, I have to run terraform plan, read 1 warning along with â(and 9 more similar warnings elsewhere)â, fix it, then run terraform plan again, read the warning with â(and 8 more similar warnings elsewhere)â, repeat until all warnings are resolved. Is there a better way?
Is there a way to have Terraform output all warnings rather than fix â(and 9 more similar warnings elsewhere)â until there are no warnings left? Like -verbose-warnings or something similar?
There isnât an explicit way to turn off the âsimilar warnings elsewhereâ truncation, but as a workaround I believe you can force Terraform to show all of the warnings by introducing at least one validation error too. Terraform should show the warnings in full if they are accompanied by at least one error.
It will need to be an error that doesnât prevent Terraform from processing the parts of the file that the warnings apply to, of course⌠one idea would be to add an invalid extra argument to one of your resource blocks so that it will fail validation, which shouldnât block any of the warnings because resource validation happens after initial configuration parsing.
For the âinterpolation-only expressionsâ warning, if you are comfortable working with a Go codebase yourself you might be interested in my side-project tool terraform-clean-syntax, which can take care of most examples of that warning automatically. It has some quirks/bugs because I threw it together quickly, but it should either produce a valid result or change nothing at all. You can use git diff to review what it did and make sure it all looks reasonable.
Since this topic is bumped to the top again, I suppose I can also mention that much of the functionality of my terraform-clean-syntax tool is now built in to terraform fmt in recent Terraform versions, so if you still have some legacy-style syntax warnings to work through then one way to go would be to use Terraform v0.15 just to run terraform fmt (assuming youâre still upgrading an earlier version and arenât ready for v0.15 yet otherwise) and then continue working with whatever other v0.12-or-later version you were already using.
The terraform fmt in v0.15 wonât produce any syntax that v0.13 and v0.14 canât also parse.
Thanks for that. In my case, I wasnât getting warnings that terraform fmt would resolve. Itâs the new warnings around "does not declare a provider named aws" and the suggestion to, "add an entry for aws in the required_providers block within the module." This used to be purely optional, but apparently now itâs a warning.
Thereâs also the similar-ish warning around using an aliased provider block, "Remove the aws.<ALIAS> provider block from module.<MODULE>. Add aws.<ALIAS> to the list of configuration_aliases for aws in required_providers to define the provider configuration name."
I just wanted to see all the warnings so I could better plan out the updates I need to make.
Detail Address Filename Line
------ ------- -------- ----
Use the aws_s3_bucket_acl resource instead module.efs_backup.aws_s3_bucket.efs_backup modules/efs_backup/s3.tf 4
Use the aws_s3_bucket_lifecycle_configuration resource instead module.efs_backup.aws_s3_bucket.efs_backup modules/efs_backup/s3.tf 1
Use the aws_s3_bucket_acl resource instead aws_s3_bucket.config_recorder_bucket aws-config.tf 191
Supposedly, the work of adding supression is greater than just listing all warnings⌠so the code is there. Itâd be wonderful if there was a command line option to disable this.
It is true that there is already code that could in principle show all of the warnings, but there isnât any code to handle it being a configurable option and it is that code that we donât wish to add and maintain in all future versions of Terraform, in addition to the existing option to choose between the normal console output vs. the machine-readable JSON output which already allows you to filter or not filter in whatever way you need.
Indeed, Terraform already has enough options that they create maintenance burden. Hence, we avoid adding new ones unless they allow meeting a new use-case that cannot be met any other way.
There is already a way to view all of the diagnostics and filter them however you wish, as described earlier in this topic. If you want to see the warnings differently than the default UI presents them then that is the way to do it.
It is of course your product, giving you the right to do with it as you wish.
But, can you understand that itâs a rather baffling for users to be told that a simple CLI flag merely to turn off the existing warning summarization functionality is deemed to be an overly oppressive maintenance burden, in comparison to major new features still being added to the product?
I could be wrong, but it sounds like the feature talked about here would pretty much be just 1 CLI flag and 1 if statement. For that to be too burdensome, but the new features from 1.2 and lined up for 1.3 to not be ⌠I just donât know how to understand that decision-making process.
First you hide sensitive values without ability to show them after terraform plan that force people to use jq and other hacky way of making diff and searching what change and why, then again do changes like this to hide warnings.
Sorry but this is not the right direction for any project.
If you introduce such changes give at least ability in cli by using switches to act in old ways,
we are adults and donât need such extra protection.
