terraform

Commit Graph

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	3 months ago
Martin Atkins	6f84623cb6	terraform: Initial partial support for ephemeral values 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.	2 years ago

Author

SHA1

Message

Date

Radek Simko

0fe906fa8c

make copyrightfix

Martin Atkins

6f84623cb6

terraform: Initial partial support for ephemeral values

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.

2 Commits (add-missing-variable-loading)