This caused a bunch of mechanical changes to callers, of course. Expression
evaluation is a very cross-cutting concern, so updating everything all at
once would be a lot and so this stops at a mostly-arbitrary point wiring
a bunch of callers to pass in contexts without changing anything that has
lots of callers.
We'll continue pulling on this thread in later commits.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Because of the support for provider-contributed functions, expression
evaluation can potentially cause provider gRPC requests to happen, and so
we'll need to be able to plumb OpenTelemetry trace information through to
those calls.
This initial commit focuses mainly on just getting the functions in
lang.Scope set up to take context.Context, along with their companions in
configs.StaticEvaluator, while leaving most of the callers just passing
context.TODO() for now so we can gradually deal with the rest of the
plumbing in later commits.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Continuing the ongoing work of getting context.Context wired in everywhere
we might want to generate OpenTelemetry traces, this completes all of the
provider-related methods of EvalContext.
Unfortunately there is still one remaining path not included here: the
EvalContext.EvaluationScope method needs to somehow arrange for contexts
to reach the provider-defined functions so that we can pass the context
to providers.Interface.CallFunction, which is tricky because that has to
get through the cty function API that wasn't designed for functions that
are backed by network calls. We'll deal with that in a subsequent commit
because it's likely to be a more invasive change than the
relatively-mechanical wiring updates included here.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The graph node types related to resources and resource instances use a
bunch of helper functions in different combinations, rather than calling
directly into the provider API.
This commit plumbs context.Context through to the functions that _do_
eventually call methods directly on the provider object, leaving us just
one more step away from plumbing the context through to the actual gRPC
calls. The next step (in a future commit) will be to update the
providers.Interface methods to take context.Context arguments and then
have the gRPC-based implementations of that interface pass the context
through to the gRPC client stub calls, and then we should be pretty close
to being able to turn on OTel tracing instrumentation for our gRPC
client requests.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
As part of our continuing effort to plumb context.Context everywhere we
might want to generate tracing spans, this is a first tentative step to
retrofitting the EvalContext interface.
This is a _huge_ interface, so a single commit updating all of the methods
would be too much to deal with. Instead, we'll start small and focus only
on the provider schema lookup because at this point that's the one
remaining part of the core language runtime that makes
potentially-expensive external requests but isn't yet able to generate
tracing spans, and so currently the time spent on this gets misattributed
to whichever caller is unfortunate enough to ask for the schema first and
thus becomes responsible for populating the schema cache.
The callers of this method are not yet plumbed for context themselves, so
a subsequent commit will replace these new context.TODO() calls with
something more useful.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
