This new field will be consumed in order to redact sensitive values referenced in a list block's input configuration from the query logs. We simply pipe the config schema and the marked values, and include the paths in the query_start log output.
We'd previously removed all other references to "lifecycle" actions, which made this reference stand out. ResourceLifecycleActionTrigger is probably the most accurate name, but as this type just needs to be differentiated from InvokeActionTrigger I thought "resource" was enough (and I specifically wanted= to avoid lifecycle at all). I'm not super attached to the name, but I did think it would be clearer if we avoided Lifecycle as much as possible, since that's got some overlap with action subtypes.
In this instance, we call it a LifecycleActionTrigger because it's come from the resource's `lifecycle` block. This doesn't directly relate to the concept of LifecycleActions - even if we expand the design to have multiple action types (for example generic and lifecycle actions), both those actions types would use this same Trigger struct.
We want to be able to give better information if e.g. the entire module is stored in a local and the deprecated value is only later used.
Where the diag is emitted we might only see the local and not the true origin of the deprecation
A string identifying the source of the deprecation should help
The Resource struct didn't really match the data structure. Refactor
this to make it easier to break up the config generation calls so we can
pass in final config from the provider.
* WIP
* Reuse plan command for query CLI
* Basic CLI output
* Only fail a list request on error
* poc: store query results in separate field
* WIP: odd mixture between JSONs
* Fix list references
* Separate JSON rendering
The structured JSON now only logs a status on which list query is
currently running. The new jsonlist package can marshal the query fields
of a plan.
* Remove matcher
* Store results in an extra struct
* Structured list result logging
* Move list result output into hooks
* Add help text and additional flag
* Disable query runs with the cloud backend for now
* Review feedback
This is a checkpoint commit on the path to supporting ephemeral values as
a cross-cutting concern in the Terraform language. An ephemeral value is
one that lives only in RAM during a single phase and so cannot persist
from the plan phase to the apply phase, or between consecutive plan/apply
rounds.
Terraform tracks whether each value is ephemeral using the cty "marks"
concept, thus achieving the same dynamic analysis as we already employ for
the concept of "sensitive values" that prevents displaying a value in the
user interface.
This commit is just a starting point which gets some of the basics into
place:
- input variables and output values can both be statically declared as
being ephemeral. Only ephemeral inputs/outputs can have ephemeral values
assigned to them, and the recipient of the value sees it as ephemeral
even if the assigned value was not already ephemeral.
This creates a dynamic analysis cutoff point at module boundaries so
that it's possible to determine in isolation whether a single module is
using ephemeral values correctly, without having to test it in every
possible calling context.
- Managed and data resources cannot have ephemeral values assigned into
their configurations because Terraform and providers both expect the
resource attributes to persist between phases.
- Ephemeral values _can_ be used in provider and provisioner
configurations, because both of those effectively meet the definition
of the new "ephemeral" concept despite it not previously having a name.
- Ephemeral markings propagate through all of the built-in language
features for dynamic analysis purposes, largely relying on cty's efforts
to do that in similar vein as for sensitive marks. In particular,
it's possible to define a local value whose expression produces
an ephemeral result, and passing ephemeral values to functions should
propagate the ephemeral mark to the results when appropriate. (I've not
yet thoroughly reviewed all of the built-in functions for correct
marks handling though, so there may be some gaps to address in later
commits.)
The next step for this work will be to change the modules runtime to have
support for a workflow involving ephemeral _root_ input variables, where
their values must be re-supplied during the apply phase. That will then
achieve (in experimental capacity) the first goal of ephemeral values: to
be able to provide non-persistent settings such as time-limited API tokens
to use in provider configuration blocks.
* terraform: remove redundant code
NodeDestroyResourceInstance is never instantiated with a DeposedKey of anything other than states.NotDeposed, so the deleted code is never run. Deposed objects get a NodeDestroyDeposedResourceInstanceObject instead.
* tfdiags: add helper func
* configs: introduce removed block type
* terraform: add forget action
* renderer: render forget actions
* terraform: deposed objects can be forgotten
Deposed objects encountered during planning spawn
NodePlanDeposedResourceInstanceObject, which previously generated a
destroy change. Now it will generate a forget change if the deposed
object is a forget target, and a destroy change otherwise.
The apply graph gains a new node type,
NodeForgetDeposedResourceInstanceObject, whose execution simply removes
the object from the state.
* configs: add RemoveTarget address type
* terraform: modules can be forgotten
* terraform: error if removed obj still in config
* tests: better error on restore state fail
* Update CHANGELOG.md
* command: keep our promises
* remove some nil config checks
Remove some of the safety checks that ensure plan nodes have config attached at the appropriate time.
* add GeneratedConfig to plan changes objects
Add a new GeneratedConfig field alongside Importing in plan changes.
* add config generation package
The genconfig package implements HCL config generation from provider state values.
Thanks to @mildwonkey whose implementation of terraform add is the basis for this package.
* generate config during plan
If a resource is being imported and does not already have config, attempt to generate that config during planning. The config is generated from the state as an HCL string, and then parsed back into an hcl.Body to attach to the plan graph node.
The generated config string is attached to the change emitted by the plan.
* complete config generation prototype, and add tests
* Plannable import: Add generated config to json and human-readable plan output
---------
Co-authored-by: Katy Moe <katy@katy.moe>
