This adds more detailed OTel trace spans to our various different
interactions with OCI repositories, which is helpful to understand the
time spent in each of the various sequential steps involved in resolving
an OCI artifact.
OTel's centrally-maintained conventions for attribute names currently only
have a standard for reporting a manifest digest, so we'll use that where
it's appropriate but use our own "opentofu.oci."-prefixed attribute names
for everything else for now. Hopefully the upstream standard will be
broadened later to include some additional concepts, at which point we
can switch over to the standardized attribute names.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a new implementation of go-getter's "Getter" interface intended
to support installing OpenTofu module packages from OCI Distribution
repositories.
Since this is currently only intended for OpenTofu's use it makes some
simplifying assumptions that would not be acceptable for an upstream
getter, but are okay for the limited way that OpenTofu's module installer
uses go-getter, which is already intentionally constrained and hidden
behind a simpler API so we can treat go-getter as purely an implementation
detail.
This commit only introduces the getter, without actually registering it
as available for use in the module package fetcher used by "tofu init",
and so this is effectively just a bunch of dead code. A later commit will
wire this in properly and introduce an end-to-end test to demonstrate that
it's properly integrated.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This continues our work to follow the dependency inversion style for the
"package fetcher" component of the module installer.
Mimicking the existing pattern for providers, package main is now
responsible for instantiating the PackageFetcher and providing it to
the "command" package as a field of command.Meta.
We could potentially go further here and follow dependency inversion style
for _all_ of the special clients needed by the various go-getter getters,
but our primary concern for now is preparing to add a new "getter" for
installation from an OCI Distribution repository, and so we'll leave the
other already-working code unchanged to reduce the risk of this initial
work.
Future commits will actually wire in the implementation details for OCI
Repository access. This commit focuses only on plumbing the necessary
objects through the API layers.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
