Commit Graph

28255 Commits

Author SHA1 Message Date
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
James Bardin 0c8b4ce755 add context to UgpradeResourceState diags
This path was not yet using diagnostics, and returned simple errors.
2021-04-28 14:09:28 -04:00
Martin Atkins 89f986ded6 command+backend: generalized "plan mode"
So far we've only had "normal mode" and "destroy mode", where the latter
is activated either by "terraform plan -destroy" or "terraform destroy".

In preparation for introducing a third mode "refresh only" this
generalizes how we handle modes so we can potentially deal with an
arbitrary number of modes, although for now we only intend to have three.

Mostly this is just a different implementation of the same old behavior,
but there is one small user-visible difference here: the "terraform apply"
command now accepts a -destroy option, mirroring the option of the same
name on "terraform plan", which in turn makes "terraform destroy"
effectively a shorthand for "terraform apply -destroy".

This is intended to make us consistent that "terraform apply" without a
plan file argument accepts all of the same plan-customization options that
"terraform plan" does, which will in turn avoid us having to add a new
alias of "terraform plan" for each new plan mode we might add. The -help
output is changed in that vein here, although we'll wait for subsequent
commit to make a similar change to the website documentation just so we
can deal with the "refresh only mode" docs at the same time.
2021-04-27 08:23:54 -07:00
Martin Atkins c6a7d080d9 core: Generalize the idea of a "plan mode", vs just destroy flag
Previously there were only two planning modes: normal mode and destroy
mode. In that context it made sense for these to be distinguished only by
a boolean flag.

We're now getting ready to add our third mode, "refresh only". This
establishes the idea that planning can be done in one of a number of
mutually-exclusive "modes", which are related to but separate from the
various other options that serve as modifiers for the plan operation.

This commit only introduces the new plans.Mode type and replaces the
existing "destroy" flag with a variable of that type. This doesn't cause
any change in effective behavior because Terraform Core still supports
only NormalMode and DestroyMode, with NewContext rejecting an attempt to
create a RefreshMode context for now.

It is in retrospect a little odd that the "destroy" flag was part of
ContextOpts rather than just an argument to the Plan method, but
refactoring that would be too invasive a change for right now so we'll
leave this as a field of the context for now and save revisiting that for
another day.
2021-04-27 08:23:54 -07:00
Alisdair McDiarmid c89004d223 core: Add sensitive provider attrs to JSON plan
When rendering a stored plan file as JSON, we include a data structure
representing the sensitivity of the changed resource values. Prior to
this commit, this was a direct representation of the sensitivity marks
applied to values via mechanisms such as sensitive variables, sensitive
outputs, and the `sensitive` function.

This commit extends this to include sensitivity based on the provider
schema. This is in line with the UI rendering of the plan, which
considers these two different types of sensitivity to be equivalent.

Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2021-04-27 10:29:34 -04:00
upodroid 5a60db0974 replace gomod 2021-04-26 14:34:11 +01:00
upodroid 958eb20559 remove json key content 2021-04-26 14:27:33 +01:00
upodroid b243dbd93d Merge branch 'main' of github.com:hashicorp/terraform into gcs-imp-v2 2021-04-26 14:20:28 +01:00
James Bardin 4997b9b5bb
Merge pull request #28424 from hashicorp/jbardin/dynamic
Better planing of unknown dynamic blocks
2021-04-23 18:26:21 -04:00
James Bardin 0830e8be70
Merge pull request #28504 from hashicorp/pgp-pubkey-0.15
update HC Public Key
2021-04-23 12:21:47 -04:00
James Bardin a4a6b40bee update getproviders tests for new key 2021-04-23 11:18:58 -04:00
James Bardin e1d790be61 update HC PublicKey 2021-04-23 11:18:58 -04:00
Kristin Laemmert 80f01e2cb7
Update CHANGELOG.md 2021-04-23 10:39:24 -04:00
Kristin Laemmert f6af7b4f7a
lang/funcs: add (console-only) TypeFunction (#28501)
* lang/funcs: add (console-only) TypeFunction

The type() function, which is only available for terraform console,
prints out the type of a given value. This is mainly intended for
debugging - it's nice to be able to print out terraform's understanding
of a complex variable.

This introduces a new field for Scope: ConsoleMode. When ConsoleMode is true, any additional functions intended for use in the console (only) may be added.
2021-04-23 10:29:50 -04:00
Chris Arcand 15b6a1614c
Merge pull request #28479 from hashicorp/motd-for-tfc
New login success output for TFC/E
2021-04-22 09:13:56 -05:00
Chris Arcand 58ec68063b Split off error MOTD error logging
The error logging in outputDefaultTFCLoginSuccess() is an unrelated side
effect.
2021-04-22 09:05:57 -05:00
Rachel Sharp 98ce186be9
Merge pull request #28443 from hashicorp/res-add-learn-link-debug-1
Add Learn link to Debugging
2021-04-21 22:59:19 -04:00
Chris Arcand 4b97411890 Add purple to the list of colorstring codes
This is the first color code introduced for 256 color terminals, and
should be a safe addition when considering the oldest supported
platform.
2021-04-21 21:35:45 -05:00
Chris Arcand 58cba1dea3 Add customized login success output for TFC/E
When logging in to Terraform Cloud or Terraform Enterprise, change the
success output to be a bit more customized for the platform. For
Terraform Cloud, fetch a dynamic welcome banner that intentionally fails
open and defaults to a hardcoded message if its not available for any
reason.
2021-04-21 21:23:42 -05:00
Kristin Laemmert 5ae4c2f92b lang/funcs: Defaults handling of marked arguments
Defaults will now preserve marks from non-null inputs and apply marks from any default values used. I've added tests for various structural types with marks, as well as some basic unknown cases.
2021-04-21 16:09:09 -04:00
Kristin Laemmert b34588ffca lang/funcs: TransposeFunc Tests
This commit adds test cases to TestTranspose to document how this function handles marks.

The short version is that any marks anywhere will be applied to the return value, be they marks on the input map or marks on elements (either the entire list of strings, or individual elemnets of those lists).
2021-04-21 16:09:09 -04:00
Alisdair McDiarmid 389415ab18
Merge pull request #28472 from hashicorp/alisdair/submodule-outputs-inferred-sensitive
core: Loosen output value sensitivity requirement
2021-04-21 14:40:52 -04:00
Alisdair McDiarmid 43bf3832d5 core: Loosen output value sensitivity requirement
Non-root module outputs no longer strip sensitivity marks from their
values, allowing dynamically sensitive values to propagate through the
configuration. We also remove the requirement for non-root module
outputs to be defined as sensitive if the value is marked as sensitive.

This avoids a static/dynamic clash when using shared modules that might
unknowingly receive sensitive values via input variables.

Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
2021-04-21 14:27:03 -04:00
Martin Atkins bfd4c964ee dependencies: update cty from v1.8.1 to v1.8.2
This includes the improvements to various collection-related functions to
make them handle marks more precisely. For Terraform in particular that
translates into handling sensitivity more precisely, so that non-sensitive
collections that happen to contain sensitive elements won't get simplified
into wholly-sensitive collections when using these functions.
2021-04-21 09:49:56 -07:00
Kristin Laemmert b649a8ddd1
deps: update go-plugin to v1.4.1 (#28465)
+ go mod tidy
2021-04-21 11:41:22 -04:00
James Bardin f8493bf5cd update hcl
update to v2.10.0
2021-04-20 17:04:56 -04:00
James Bardin d15f7394a1
Merge pull request #28457 from hashicorp/jbardin/provisioner-null-checks
additional null checks in provisioners
2021-04-20 16:25:34 -04:00
James Bardin 7f571b5ebb additional null checks in provisioners
Now that provisioners for directly with the plugin API and cty data
types, we need to add a few null checks to catch invalid input that
would have otherwise been masked by the legacy SDK.
2021-04-20 12:31:32 -04:00
John Houston fabdf0bea1
Add config_paths and drop KUBECONFIG env variable in kubernetes backend (#26997) 2021-04-20 10:05:45 -04:00
Martin Atkins 14336ae6f8 lang/funcs: Conversion functions can handle sensitive values
In order to avoid updating every one of our existing functions with
explicit support for sensitive values, there's a default rule in the
functions system which makes the result of a function sensitive if any
of its arguments contain sensitive values.

We were applying that default to the various type conversion functions,
like tomap and tolist, which meant that converting a complex-typed value
with a sensitive value anywhere inside it would result in a
wholly-sensitive result.

That's unnecessarily conservative because the cty conversion layer (which
these functions are wrapping) already knows how to handle sensitivity
in a more precise way. Therefore we can opt in to handling marked values
(which Terraform uses for sensitivity) here and the only special thing
we need to do is handle errors related to sensitive values differently,
so we won't print their values out literally in case of an error (and so
that the attempt to print them out literally won't panic trying to
extract the marked values).
2021-04-19 12:10:50 -07:00
Martin Atkins 8f233cde4c cli: Diagnostics can include collections with sensitive elements
We previously had a shallow IsMarked call in compactValueStr's caller but
then a more-conservative deep ContainsMarked call inside compactValueStr
with a different resulting message. As well as causing an inconsistency
in messages, this was also a bit confusing because it made it seem like
a non-sensitive collection containing a sensitive element value was wholly
sensitive, making the debug information in the diagnostic messages not
trustworthy for debugging certain varieties of problem.

I originally considered just removing the redundant check in
compactValueStr here, but ultimately I decided to keep it as a sort of
defense in depth in case a future refactoring disconnects these two
checks. This should also serve as a prompt to someone making later changes
to compactValueStr to think about the implications of sensitive values
in there, which otherwise wouldn't be mentioned at all.

Disclosing information about a collection containing sensitive values is
safe here because compactValueStr only discloses information about the
value's type and element keys, and neither of those can be sensitive in
isolation. (Constructing a map with sensitive keys reduces to a sensitive
overall map.)
2021-04-19 11:58:49 -07:00
sanflores 751fba49a7
website: v0.15 upgrade guide had invalid example for tomap(...)
tomap expects an object value with braces, not a tuple value with brackets.
2021-04-19 10:20:03 -07:00
James Bardin a0f221d04b
Merge pull request #28444 from hashicorp/jbardin/destroy-plan-provider
wrong operation during destroy plan walk
2021-04-19 13:15:42 -04:00
James Bardin 877348c031 wrong operation during destroy plan walk
The destroy plan walk was identifying itself as a normal plan, and
causing providers to be configured when they were not needed. Since the
provider configuration may not be complete during the minimal destroy
plan walk, validation or configuration may fail.
2021-04-19 12:35:10 -04:00
Rachel Sharp 56483d10d2
Update debugging.html.md 2021-04-19 12:18:02 -04:00
Kristin Laemmert 85adad0ec7
docs: small update for provider binary locations (#28413)
* docs: add note that provider binaries need to be placed in appropriate subdirectories under the default locations
2021-04-19 09:04:46 -04:00