Commit Graph

28181 Commits

Author SHA1 Message Date
CJ Horton 8161bc3ab9 backend/remote: clearer error when org read fails
When we fail to read the organization entitlements, it's not
always because the organization doesn't exist; in practice, it's
usually due to a misspelled organization name, forgetting to
specify the correct hostname, or an invalid API token. Surfacing
more information within the error message will help new users
debug these issues more effectively.
2021-05-12 13:50:11 -07:00
Rachel Sharp 87c9e78666
Merge pull request #28604 from hashicorp/res-lifecycle-tutorial
Add link to lifecycle tutorial
2021-05-07 13:01:25 -05:00
Alisdair McDiarmid fb53259907
Merge pull request #28644 from hashicorp/alisdair/length-lookup-marks-fixes
Improve marks support for `length` and `lookup`
2021-05-07 13:54:39 -04:00
Alisdair McDiarmid dbe5272931 functions: Improve marks support for lookup
Several changes to lookup to improve how we handle marked values:

- If the entire collection is marked, preserve the marks on any result
  (whether successful or fallback)
- If a returned value from the collection is marked, preserve the marks
  from only that value, combined with any overall collection marks
- Retain marks on the fallback value when it is returned, combined with
  any overall collection marks
- Include marks on the key in the result, as otherwise the result it
  ends up selecting could imply what the sensitive value was
- Retain collection marks when returning an unknown value for a not
  wholly-known collection

See also https://github.com/zclconf/go-cty/pull/98
2021-05-07 12:55:40 -04:00
James Bardin 3252df4b91
Merge pull request #28640 from hashicorp/jbardin/configload-diags
Don't try to build the config if there were errors loading
2021-05-07 12:32:45 -04:00
James Bardin ced676d50d fixed configloader doesn't add unnecessary diags 2021-05-07 12:28:09 -04:00
Alisdair McDiarmid e0c6b3fcda functions: Improve marks support for length
Similar to cty's implementation, we only need to preserve marks from the
value itself, not any nested values it may contain. This means that
taking the length of an umarked list with marked elements results in an
unmarked number.
2021-05-07 11:57:37 -04:00
James Bardin 655f18c393 don't build a config if it didn't load properly 2021-05-07 11:52:06 -04:00
Martin Atkins 8d4d333efe core: If we refresh during orphan processing, use the result for planning
If we don't do this then we can create a situation where refresh detects
that an object already doesn't exist but we plan to destroy it anyway,
rather than returning "no changes" as expected.
2021-05-06 13:26:37 -07:00
James Bardin ecd030eb26
Merge pull request #28624 from hashicorp/jbardin/schema-value-marks
null check in ValueMarks
2021-05-06 11:28:34 -04:00
James Bardin d76a8fcf6c null check in ValueMarks 2021-05-06 11:08:20 -04:00
Alisdair McDiarmid 91cdde1d67
Merge pull request #28608 from hashicorp/alisdair/json-plan-replace-paths
jsonplan: Add replace_paths
2021-05-06 08:23:09 -04:00
Martin Atkins 3443621227 core: Track both previous run state and refresh state during planning
The "previous run state" is our record of what the previous run of
Terraform considered to be its outcome, but in order to do anything useful
with that we must ensure that the data inside conforms to the current
resource type schemas, which might be different than the schemas that were
current during the previous run if the relevant provider has since been
upgraded.

For that reason then, we'll start off with the previous run state set
exactly equal to what was saved in the prior snapshot (modulo any changes
that happened during a state file format upgrade) but then during our
planning operation we'll overwrite individual resource instance objects
with the result of upgrading, so that in a situation where we successfully
run plan to completion the previous run state should always have a
compatible schema with the "prior state" (the result of refreshing) for
managed resources, and thus the caller can meaningfully compare the two
in order to detect and describe any out-of-band changes that occurred
since the previous run.
2021-05-05 15:11:05 -07:00
Martin Atkins 7c6e78bcb0 plans: Track both the previous run and prior states in the plan
Until now we've not really cared much about the state snapshot produced
by the previous Terraform operation, except to use it as a jumping-off
point for our refresh step.

However, we'd like to be able to report to an end-user whenever Terraform
detects a change that occurred outside of Terraform, because that's often
helpful context for understanding why a plan contains changes that don't
seem to have corresponding changes in the configuration.

As part of reporting that we'll need to keep track of the state as it
was before we did any refreshing work, so we can then compare that against
the state after refreshing. To retain enough data to achieve that, the
existing Plan field State is now two fields: PrevRunState and PriorState.

This also includes a very shallow change in the core package to make it
populate something somewhat-reasonable into this field so that integration
tests can function reasonably. However, this shallow implementation isn't
really sufficient for real-world use of PrevRunState because we'll
actually need to update PrevRunState as part of planning in order to
incorporate the results of any provider-specific state upgrades to make
the PrevRunState objects compatible with the current provider schema, or
else our diffs won't be valid. This deeper awareness of PrevRunState in
Terraform Core will follow in a subsequent commit, prior to anything else
making use of Plan.PrevRunState.
2021-05-05 15:11:05 -07:00
Kristin Laemmert 5f30efe857
command tests: plan and init (#28616)
* command/init: add test for reconfigure

* command/plan: adding tests

* command/apply: tests

* command: show and refresh tests
2021-05-05 14:13:20 -04:00
James Bardin 1e3a60c7ac
Merge pull request #28606 from hashicorp/jbardin/providers-in-modules
Validate passing default providers through modules
2021-05-05 09:07:02 -04:00
Alisdair McDiarmid 0ab7d901d9
Merge pull request #28607 from hashicorp/alisdair/cty-1.8.3
Upgrade cty to 1.8.3
2021-05-04 17:30:38 -04:00
Alisdair McDiarmid b0f44fc293 go get github.com/zclconf/go-cty@v1.8.3 2021-05-04 17:01:37 -04:00
Alisdair McDiarmid a5b7394f9a command/jsonplan: Add replace_paths
The set of paths which caused a resource update to require replacement
has been stored in the plan since 0.15.0 (#28201). This commit adds a
simple JSON representation of these paths, allowing consumers of this
format to determine exactly which paths caused the resource to be
replaced.

This representation is intentionally more loosely encoded than the JSON
state serialization of paths used for sensitive attributes. Instead of a
path step being represented by an object with type and value, we use a
more-JavaScripty heterogenous array of numbers and strings. Any
practical consumer of this format will likely traverse an object tree
using the index operator, which should work more easily with this
format. It also allows easy prefix comparison for consumers which are
tracking paths.

While updating the documentation to include this new field, I noticed
that some others were missing, so added them too.
2021-05-04 16:51:51 -04:00
James Bardin 168296b507 validate that modules name providers passed to mod
Passing a provider into a module requires that it be named within the
module. This would previously pass validation, however core would fail
to resolve the provider resulting in an unclear "provider not found"
error.
2021-05-04 16:41:04 -04:00
Rachel Sharp c302fa507f
Add link to lifecycle tutorial 2021-05-04 14:20:22 -04:00
Alisdair McDiarmid 53fab10b26
Merge pull request #28598 from hashicorp/alisdair/fix-diagnostic-snippet-crash
cli: Fix diagnostic snippet crash
2021-05-04 13:01:58 -04:00
Kristin Laemmert 3679de0630
command/format: fix repetitive "unchanged attribute hidden" message (#28589)
writeNestedAttrDiff and writeAttrDiff were both printing the "unchanged attribute" message.  This removes one of the redundant prints.

Fixing this led me (in a very roundabout way) to realize that NestedType attributes were printing a sum total of unchanged attributes, including those in entirely unchanged elements, while *not* printing the total of unchanged elements. I added the necessary logic to count and print the number of unchanged elements for maps and lists.
2021-05-04 10:23:50 -04:00
Chris Arcand 5813620412
Merge pull request #28594 from hashicorp/go-tfe-update
Update go-tfe client to v0.14.0
2021-05-04 09:11:19 -05:00
Alisdair McDiarmid 25f99857cf cli: Fix crash with invalid JSON diagnostics
If a JSON diagnostic value has a highlight end offset which is before
the highlight start offset, this would previously panic. This commit
adds a normalization step to prevent the crash.
2021-05-04 08:35:42 -04:00
Alisdair McDiarmid 3a9b369b43 views/json: Fix diag crash with invalid highlight
Some diagnostic sources (I'm looking at you, HCL) fail to set the end of
the subject range. This is a bug in those code paths, but we can ensure
that we generate valid JSON diagnostics by checking for it here.

By doing so before the range normalization, we ensure that we generate a
unit width highlight whenever possible, so that at least something
useful is displayed.
2021-05-04 08:35:42 -04:00
Alisdair McDiarmid e9c9092c40 Fix missing trailing newline 2021-05-04 08:31:39 -04:00
Chris Arcand 2756f5ed08 Update Terraform Cloud/Enterprise client to v0.14.0 2021-05-03 22:25:56 -05:00
Martin Atkins c63c06d3c4 core: -replace to emit only one warning for incomplete address
If the user gives an index-less address for a resource that expects
instance keys then previously we would've emitted one error per declared
instance of the resource, which is overwhelming and not especially
helpful.

Instead, we'll deal with that check prior to expanding resources into
resource instances, and thus we can report a single error which talks
about all of the instances at once.

This does unfortunately come at the expense of splitting the logic for
dealing with the "force replace" addresses into two places, which will
likely make later maintenance harder. In an attempt to mitigate that,
I've included a comment in each place that mentions the other place, which
hopefully future maintainers will keep up-to-date if that situation
changes.
2021-05-03 15:43:23 -07:00
Martin Atkins 1d3e34e35e command: New -replace=... planning option
This allows a similar effect to pre-tainting an object but does the action
within the context of a normal plan and apply, avoiding the need for an
intermediate state where the old object still exists but is marked as
tainted.

The core functionality for this was already present, so this commit is
just the UI-level changes to make that option available for use and to
explain how it contributed to the resulting plan in Terraform's output.
2021-05-03 15:43:23 -07:00
James Bardin f738246a03 add default provider nodes to root modules
If a root modules declares a required_provider but has no configuration,
add a graph node for the provider as if there were an empty
configuration. This will allow the provider to be referenced by name in
module call provider maps, so that a module can pass a default provider
by name to a submodule.

Normally these nodes are added by the MissingProviderTransformer, but
they need to be in place earlier to resolve any possible "proxy provider
nodes" within modules.
2021-05-03 16:27:08 -04:00
Alisdair McDiarmid 7f39f19ec7
Merge pull request #28584 from hashicorp/alisdair/add-reason-to-json-planned-change
command/views: Add reason to JSON planned change
2021-05-03 09:37:27 -04:00
Alisdair McDiarmid 48b9055e42
Merge pull request #28583 from hashicorp/alisdair/sensitive-attribute-forces-replacement
cli: Show forces replacement for sensitive attrs
2021-05-03 09:35:04 -04:00
Alisdair McDiarmid 7b23fa7877 command/views: Add reason to JSON planned change
Now that we have extra information about the reason for a given resource
action, include that in the JSON log output for planned changes.
2021-05-03 06:49:42 -04:00
Alisdair McDiarmid c95e9ada6b cli: Show forces replacement for sensitive attrs
When rendering a plan diff, sensitive resource attributes would
previously omit the "forces replacement" comment, which can lead to
confusion when the only reason for a resource being replaced is a
sensitive attribute.
2021-05-03 06:48:10 -04:00
Martin Atkins 6bed3008a5 website: Reworking of the "terraform plan" docs, and related pages
It's been a long time since we gave this page an overhaul, and with our
ongoing efforts to make plan and apply incorporate all of the side-effects
that might need to be done against a configuration it seems like a good
time for some restructuring in that vein.

The starting idea here is to formally split the many "terraform plan"
options into a few different categories:
 - Planning modes
 - Planning options
 - Other options

The planning modes and options are the subset that are also accepted by
"terraform apply" when it's running in its default mode of generating a
plan and then prompting for interactive approval of it. This then allows
us to avoid duplicating all of that information on the "terraform apply"
page, and thus allows us to spend more words discussing each of them.

This set of docs is intended as a fresh start into which we'll be able to
more surgically add in the information about -refresh-only and -replace=...
once we have those implemented. Consequently there are some parts of this
which may seem a little overwraught for what it's currently describing;
that's a result of my having prepared this by just deleting the
-refresh-only and -replace=... content from our initial docs draft and
submitted the result, in anticipation of re-adding the parts I've deleted
here in the very near future in other commits.
2021-04-30 14:27:36 -07:00
Alisdair McDiarmid 95b86bf7ad
Merge pull request #28566 from hashicorp/alisdair/json-logs-operations-commands
cli: Add JSON logs for operations commands
2021-04-30 14:00:02 -04:00
Martin Atkins 06adc69e2c plans: Plan.Mode is now Plan.UIMode
This is to make it more obvious at all uses of this field that it's not
something to be used for anything other than UI decisions, hopefully
prompting a reader of code elsewhere to refer to the comments to
understand why it has this unusual prefix and thus see what its intended
purpose is.
2021-04-30 10:30:56 -07:00
Martin Atkins b37b1beddd core: Minimal initial implementation of -replace=... option
This only includes the internal mechanisms to make it work, and not any
of the necessary UI changes to "terraform plan" and "terraform apply" to
activate it yet.

The force-replace options are ultimately handled inside the
NodeAbstractResourceInstance.plan method, at the same place we handle the
similar situation of the provider indicating that replacement is needed,
and so the rest of the changes here are just to propagate the settings
through all of the layers in order to reach that point.
2021-04-30 10:30:56 -07:00
Martin Atkins 1b464e1e9a core: Minimal initial implementation of "refresh only" planning mode
This only includes the core mechanisms to make it work. There's not yet
any way to turn this mode on as an end-user, because we have to do some
more work at the UI layer to present this well before we could include it
as an end-user-visible feature in a release.

At the lowest level of abstraction inside the graph nodes themselves, this
effectively mirrors the existing option to disable refreshing with a new
option to disable change-planning, so that either "half" of the process
can be disabled. As far as the nodes are concerned it would be possible
in principle to disable _both_, but the higher-level representation of
these modes prevents that combination from reaching Terraform Core in
practice, because we block using -refresh-only and -refresh=false at the
same time.
2021-04-30 10:30:56 -07:00
Sam Velie 5d04c4ea27
docs: correct spelling of normally (#28508) 2021-04-30 12:24:02 -04:00
Alisdair McDiarmid f72730a02b cli: Add JSON logs for operations commands 2021-04-30 11:37:36 -04:00
Martin Atkins b802237e03 plans: Track an optional extra "reason" for some planned actions
Previously we were repeating some logic in the UI layer in order to
recover relevant additional context about a change to report to a user.
In order to help keep things consistent, and to have a clearer path for
adding more such things in the future, here we capture this user-facing
idea of an "action reason" within the plan model, and then use that
directly in order to decide how to describe the change to the user.

For the moment the "tainted" situation is the only one that gets a special
message, matching what we had before, but we can expand on this in future
in order to give better feedback about the other replace situations too.

This also preemptively includes the "replacing by request" reason, which
is currently not reachable but will be used in the near future as part of
implementing the -replace=... plan command line option to allow forcing
a particular object to be replaced.

So far we don't have any special reasons for anything other than replacing,
which makes sense because replacing is the only one that is in a sense
a special case of another action (Update), but this could expand to
other kinds of reasons in the future, such as explaining which of the
few different reasons a data source read might be deferred until the
apply step.
2021-04-29 17:50:46 -07:00
James Bardin 2c4bd08fd9
Merge pull request #28553 from hashicorp/jbardin/un-code-cov
remove codedov
2021-04-29 13:18:54 -04:00
James Bardin 43af00262e remove codedov 2021-04-29 13:12:58 -04:00
James Bardin 479a091324
Merge pull request #28543 from hashicorp/jbardin/provider-diagnostics
Add more diagnostic configuration context to provider methods
2021-04-29 10:28:58 -04:00
James Bardin 7eade2cb52 add more diagnostics context
There were some remaining calls to provider where configuration could be
added to diagnostics, where warnings would not get config annotations,
or the diagnostics were skipped entirely.
2021-04-28 18:01:50 -04:00
Alisdair McDiarmid 4b1ff4eda7
Merge pull request #28523 from hashicorp/alisdair/json-plan-sensitive-provider-attrs
core: Add sensitive provider attrs to JSON plan
2021-04-28 15:49:47 -04:00
James Bardin 7f05d5d438
Merge pull request #28539 from hashicorp/jbardin/marked-data-plan
Unmark config values when planning a data source read
2021-04-28 14:19:25 -04:00
James Bardin 1db29d775e unmark planned data source values 2021-04-28 14:09:28 -04:00