Exclude implicit validation from plan command

Terraform
1

Hi team,

Please suggest if possible to exclude implicit validation from plan command.
We want to run sequentially validation, plan and apply but first and second if overlapping.

Thank you

2

No, it is not possible, because plan needs to load the config, so it inevitably ends up discovering the same problems that validate would, if run separately.

1 Like
3

Hi @chell0veck,

Validation is a prerequisite for doing anything further with a Terraform configuration, because if it isn’t valid then Terraform Core’s internal assumptions will be violated and the resulting behavior would be unpredictable.

Validation is not typically an expensive operation in comparison to plan and apply, because it works entirely locally and does not involve contacting external network services, so I don’t expect it would be significant to skip the implied validation step during plan, but if your particular configuration is unusual and does spend a considerable amount of time in the validation step then I’d like to hear more details about that in case there’s a different approach I can suggest.

4

Thanks @apparentlymart ,

Agree it’s not heavy but at scale every second is valuable.
Our workload is 1K states with up to 100 resources within.

Example of some measurement

PRODUCT  STATUS   LAYERS TIME   |  VALIDATION   VTIME     PLAN      PTIME     APPLY     ATIME
xxxxxxxxxx   success     5     495 |    success              147     success     200     success     148

Above is product abstraction with 5 modules and time each phase took in seconds.
I think validation is redundant in this workflow but I was driven by the idea that each stage should eliminate some class of exceptions:

  • validation - static, syntax (no api calls)
  • plan - resource duplication (actually to know what else but involve api read)
  • apply - runtime errors (resource limits, etc… - api write).

Now I think:

  • use only plan and apply
  • and plan with -detailed-exitcode arg and skip apply at all if exitcode is 0.

I don’t think our configuration if unusual - it is rather enormously big, so I’m looking to save every second in terraform, terragrunt ad in between.

5

If you are running terraform plan immediately after terraform validate in the same execution context then indeed that extra validate call is pretty redundant.

The typical use of the standalone terraform validate is to run it in a separate execution context that typically doesn’t have access to credentials for remote systems. For example, the most common case I hear about is running terraform validate as a merge-blocking check during the code review stage, and then running terraform plan in a separate place with access to credentials after the changes have been merged. In this case it’s worth the cost to do the extra validation because it helps to avoid merging patently-invalid configuration changes but avoids exposing a privileged execution context to code that hasn’t been reviewed yet.

If you are running both steps together after the change is already approved for use then separate validation seems less useful. I would consider skipping terraform validate in that case and just let the plan step do it.

1 Like
6

@apparentlymart

Bot it and thankful for the hint - I was planning to distribute validation to CI sub-flow.
But look - running validation prior merge doesn’t resolve the issue. I have following options:

  1. skip plan and run apply - that leads me to the runtime & plan time if so.
  2. run plan & apply - plan will repeat validation step.

In my case owning both CI and CD part - I don’t see benefits from decoupling validation from plan.

So when you own both parts - efficient looks to be plan&apply. But when it is distributed - validation&apply.

We had and internal discussion that either validation or plan is redundant but good t know.

7

I’m not sure I fully understand what you are describing but I do want to note that there’s a difference between running terraform plan with no arguments and then terraform apply with no arguments, vs. running terraform plan -out=tfplan and then terraform apply tfplan.

In the first case, the terraform apply command incorporates the full plan process, so you’ll end up planning twice. But if you save the plan file to disk and then apply from that plan file then the apply command will skip the plan phase and just start immediately with the apply phase, using the saved plan file to recall all of the decisions made during planning.

It isn’t possible to apply without first creating a plan, but terraform apply with no arguments hides that by automatically creating a plan first. Despite it being incorporated into the same command, it has the same cost as when run as a separate command with the results saved to a file.

Also, to be clear, I wasn’t recommending that you must run validation before merge. Instead, I meant to say that if you are not running validation before merge then there’s little reason to run terraform validate at all, because the validation done as part of terraform plan is a superset of what terraform validate would do and so a separate terraform validate adds nothing. The separate terraform validate command is only helpful if you run it at an earlier phase to give some early feedback before the configuration is reviewed, and thus before it would be safe to run terraform plan.

1 Like
8

This topic was automatically closed 62 days after the last reply. New replies are no longer allowed.