Previously we made a very generic suggestion to use -target to split a
change into two parts as a workaround for the fact that count and for_each
must be known during planning. That works, but we didn't have enough
information available to tell the operator exactly what to target and so
anyone who is not an expert on the configuration they're working with tends
to get stuck unable to figure out exactly what they need to do.
The new -exclude option gives us an opportunity to do better here: we tend
to know for which object we're currently evaluating count or for_each, and
so we can mention that object directly in the error message when if we
recommend to use -exclude instead of -target.
Not all objects that support count/for_each will necessarily be directly
targetable, so we can still potentially recommend -target when we're
dealing with one of those objects. For example, as of this commit that
is true for for_each in a provider block, because there is not currently
any syntax for specifying a provider configuration as an addrs.Targetable.
Perhaps we'll introduce such a thing in the future, but that's outside the
scope of this change that's primarily focused on improving the messaging
for resource and module count/for_each.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The original proposal called for the state snapshot loader to accept a
resource instance with both an instance-level provider instance address
and a resource-level provider instance address.
The final implementation does follow that specification, but it also emits
a warning in that case to draw attention to the inconsistency.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The original proposal called for the state snapshot writer to generate a
resource-level provider property if all of the instances of the resource
had the same provider instance address, regardless of what that address
actually is.
The actual implementation instead chose to generate the resource-level
property only if none of the instances of the resource refer to a provider
instance that has an instance key.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Kind of odd code smell, but the only alternative I could think of was a
panic. Would rather ensure this requirement at compile time instead.
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
In the main language runtime input variables have both a "raw" value as
provided by the caller and a "finalized" value that has been
type-converted, default-attributes-inserted, and validated.
Unfortunately the "early eval" codepath is essentially a reimplementation
of the language runtime in terms of data available in the static
configuration, and it previously wasn't properly emulating the finalization
of input variable values and was thus incorrectly exposing the "raw"
values into a module instead of the "finalized" values.
Since we are already in the v1.9 prerelease period significant refactoring
is too risky, and so this just copies the most important transformations
from the language runtime into the early eval runtime. We hope to find a
more sustainable way to implement this in the future, but that will likely
require refactoring of both the early eval codepath _and_ the traditional
language runtime, and so that work needs to begin early in a minor release
period.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
Earlier commits arranged for each of our tofu.Context exported methods that
perform graph-based operations to take a context.Context from their
callers, and for the main callers in package command and package backend
to connect those contexts to the top-level context from "package main"
that can potentially have an OpenTelemetry span attached to it.
This propagates those contexts a little deeper into the guts of the
language runtime, getting it as far as the shared logic that drives a
graph walk.
The next step from here would be to change the interfaces
GraphNodeExecutable and GraphNodeDynamicExpandable so that their methods
both take a context.Context, but that would involve a big sprawling
update to every implementation of each of those interfaces and so
we'll save that for a later commit to keep this one relatively clean.
This commit also reaches the first point of ambiguity where our older
conventions call for "ctx" to be the variable name for a tofu.EvalContext
rather than a context.Context. Since "ctx context.Context" is a core idiom
in the Go community, we'll switch to using evalCtx as the variable name
for tofu.EvalContext both here and in our future commits that will
modify the two main graph walk interfaces that make extensive use of the
tofu.EvalContext interface.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>