OpenTelemetry has various Go packages split across several Go modules that
often need to be carefully upgraded together. And in particular, we are
using the "semconv" package in conjunction with the OpenTelemetry SDK's
"resource" package in a way that requires that they both agree on which
version of the OpenTelemetry Semantic Conventions are being followed.
To help avoid "dependency hell" situations when upgrading, this centralizes
all of our direct calls into the OpenTelemetry SDK and tracing API into
packages under internal/tracing, by exposing a few thin wrapper functions
that other packages can use to access the same functionality indirectly.
We only use a relatively small subset of the OpenTelemetry library surface
area, so we don't need too many of these reexports and they should not
represent a significant additional maintenance burden.
For the semconv and resource interaction in particular this also factors
that out into a separate helper function with a unit test, so we should
notice quickly whenever they become misaligned. This complements the
end-to-end test previously added in opentofu/opentofu#3447 to give us
faster feedback about this particular problem, while the end-to-end test
has the broader scope of making sure there aren't any errors at all when
initializing OpenTelemetry tracing.
Finally, this also replaces the constants we previously had in package
traceaddrs with functions that return attribute.KeyValue values directly.
This matches the API style used by the OpenTelemetry semconv packages, and
makes the calls to these helpers from elsewhere in the system a little
more concise.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Earlier work made GraphBuilder.Build take a context, but we had a missing
link in the context-passing chain due to the plan and apply graph
construction being factored out into a separate unexported function.
This commit just adds the remaining few steps of plumbing so that a useful
upstream context can reach all of the graph builders, so that it'd be
okay for downstream code to generate trace spans in future.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Most of our transformers are pure compute and so don't really have a strong
need to generate trace spans under our current focus of only exposing
user-facing concepts and external requests in our traces, but unfortunately
some of them indirectly depend on provider schema, which in turn means that
they can potentially be unlucky enough to be the trigger for making all
of the provider requests needed to fill the schema cache and therefore
would end up with provider request spans being reported beneath them.
As usual with these interface updates, this initial change focuses only
on changing the interface and updating its direct callers and implementers
to match, without any further refactoring or attempts to plumb contexts
to or from other functions that don't have them yet. That means there are
a few new context.TODO() calls here that we'll tidy up in a later commit
that hopefully won't involve all of the noise that is caused by changing
an interface API.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
A good starting point for tracing the work done by OpenTofu core is to
delimit the main phases: validate, gathering input, plan, and apply.
In interactive "tofu apply" there can potentially be a long delay between
the end of plan and the start of apply while we wait for the operator
to type "yes" at the confirmation prompt, so this high-level bracketing
is a good start for distinguishing the system's own delay from delay
caused by the operator and surrounding environment.
Signed-off-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>
This continues our ongoing effort to get a coherent chain of
context.Context all the way from "package main" to all of our calls to
external components.
Context.Apply does not yet do anything with its new context, but this gets
the context plumbed in enough that we should be able to pass values like
telemetry spans all the way from the top-level in future.
OpenTofu has some historical situational private uses of context.Context
to handle the graceful shutdown behaviors. Those use context.Context as
a private implementation detail rather than public API, and so this commit
leaves them as-is and adds a new "primary context" alongside. Hopefully
in future refactoring we can simplify this to use the primary context also
as the primary cancellation signal, but that's too risky a change to bundle
in with this otherwise-mostly-harmless context plumbing.
All of the _test.go file updates here are purely mechanical additions of
the extra argument. No test is materially modified by this change, which
is intentional to get some assurance that isn't a breaking change.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
