Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flag or env var for quieting syntax deprecation warnings #23406

Closed
daveadams opened this issue Nov 18, 2019 · 10 comments · Fixed by #23425
Closed

Flag or env var for quieting syntax deprecation warnings #23406

daveadams opened this issue Nov 18, 2019 · 10 comments · Fixed by #23425

Comments

@daveadams
Copy link
Contributor

Current Terraform Version

0.12.15

Use-cases

As of this latest Terraform version, I’m now being flooded with deprecation notices for quoted provider references, type constraints, and interpolation-only expressions. Right now for some of my projects, when I run a terraform apply, I’m receiving literally thousands of lines of warning messages about syntax deprecation, and it shows up below the list of pending changes, so I have to scroll through an enormous quantity of text before I can see what changes are pending.

The current level of verbosity about the deprecated syntax is not user-friendly–I know about and am actively migrating projects to the new syntax–It only makes Terraform a pain to use safely in the interim.

Attempted Solutions

I looked in the documentation and code for a way to disable these messages and found none.

Proposal

Please add a CLI flag or env var to acknowledge these warnings and prevent them from being displayed.

Alternatively, collapse all the messages down to a single one-line warning along with instructions on how to run a separate command that would list them in detail. Or at the very least, I don't need a 12 line explanation of the issue for each time it crops up. Could the long message be displayed just once instead of hundreds of times?

@miquella
Copy link
Contributor

Alternatively, would it be possible for the code to self-proclaim that it is purposefully supporting the deprecated syntax? This would allow a more targeted suppression of the warnings rather than turning them off for the entire invocation.

Either way though, the present state of the warnings, while informative, is quite unusably verbose.

@apparentlymart
Copy link
Contributor

In #23425 I put a cap on the number of copies of the same warning that the CLI will emit, which was a reasonably quick fix we could do in order to address this quickly. It's likely we'll revisit this in future releases to continue to tweak these warnings and find a reasonable compromise between making sure these warnings are visible while making sure they aren't blocking actual use of Terraform.


While on this subject, I've also (as a quick personal project, not as an official HashiCorp thing) built a little tool to fix some of these warnings automatically.

It's similar in principle to the terraform 0.12upgrade tool, but whereas the upgrade tool uses the 0.11 parser to read and produces 0.12 syntax, this other tool uses the 0.12 (HCL 2) implementation for both reading and writing, and so it's able to run against a configuration that already contains a mixture of old-style and new-style syntax as long as Terraform 0.12 would've been able to parse it.

Hopefully that helps to make the process of switching to the new-style syntax a little less onerous. It won't catch everything, but it will hopefully catch most simple things.

@apparentlymart apparentlymart added this to the v0.12.17 milestone Nov 20, 2019
@daveadams
Copy link
Contributor Author

Great, thanks for the quick response on this @apparentlymart !

In terms of fixing the syntax, in our case, the problem involves some shared modules used by projects running both 0.12 and 0.11, and we'd really rather not split them in two if we can avoid it (we had to split several of our shared modules while teams have been migrating). But your tool looks useful for when we get to the final cleanup stage. Thanks for the tip!

@solarmosaic-kflorence
Copy link

While the fix in #23425 is reasonable, I would much rather never see this kind of noise when running apply as any distraction prior to altering remote resources is pretty unacceptable. My two cents. Seems perfectly acceptable on validate, though plan can even be dicey if you are using the plan to apply.

@benjumanji
Copy link

benjumanji commented Nov 24, 2019

It's massively user hostile. I had to use a pager to be able to read plan. Forcing people to downgrade the tool to be able to use it is crazy. I'll obviously take care of the warnings but this it such an egregious way to flag a syntax change for a form that not only was massively in use but was the mandatory correct way to do things a short while ago.

Honestly if I weren't so invested in terraform I would be looking for alternatives right now.

@kevinburke1
Copy link
Contributor

Martin's check-syntax tool fixed all of the warnings. Hopefully you can integrate it into terraform fmt, that would fix the problems automatically.

@dininski
Copy link

We are observing exactly the same issues as @benjumanji. My team does not have ownership of some shared modules, and doing apply now means that we need to use a pager in order to see what changes are actually going to be applied. Those warning are very intrusive. I would've expected the TF_LOG=ERROR to stop logging them, but that doesn't help at all.

@wwboynton
Copy link

Yeah, honestly, most other frameworks I have used will allow users to ignore deprecation warnings (at their peril) and I think this is the right choice. Please provide a flag to disable these completely. They're really awful.

@telepath
Copy link
Contributor

Can this issue please be re-opened? Unless hashicorp really has no intention of changing this, which would probably mean that people will start managing their own forks to fix unacceptable behavior.

@ghost
Copy link

ghost commented Jan 16, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Jan 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants