This commit rescopes what was originally a draft about provider
installation from OCI registries into a more general document about how
we intend to use OCI container images and OCI registries as a distribution
vehicle for at least two different kinds of OpenTofu dependency packages
(module and provider packages).
This document already had good content about how OCI registries and
artifacts work _in general_, and its associated PR was already attracting
general discussion about whether to use Docker-style or ORAS-style
conventions across both provider and module packages, so we'll now use
this document to discuss just the overall question of what style of
packaging we intend to use (across both package types) and will discuss
the module-specific and provider-specific details in other RFCs.
This also reworks the document to now propose using the Docker-like
conventions instead of the ORAS-like conventions, since that matches what
we've been exploring in prototypes. Of course, that decision is not final
until this RFC is accepted and merged, but we have considerably better
understanding of how this would work under the Docker-like approach than
ORAS and it seems like consensus is so far heading in that direction. We
may revise this document again if we learn of some strong arguments in
favor of the ORAS approach.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a lightweight RFC proposing that we adopt some cross-cutting naming
conventions for variables of various different types whose names all
include the noun "context", both to gradually improve existing confusion
and inconsistency in the codebase and in particular to un-squat the name
"ctx" that has emerged as the idiomatic name for a context.Context
elsewhere in the Go ecosystem.
This proposal does not call for any immediate code changes. It is only an
attempt to agree on some conventions to follow in future work on other
projects.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Proposal for creating a separate "tracking issue" for each accepted RFC,
which represents the implementation of the features described in that RFC
separately from the potentially-many feature request issues it aims to
address.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We currently have a set of aspirational linting rules in the project's
golangci-lint configuration, but this codebase was derived from a much
older codebase that was not written under those lint rules and so we made
the pragmatic decision that only code that has changed since the addition
of the lint rules is subjected to those lint rules.
That approach aims to make the compromise of encouraging us to gradually
improve code "while we're in the area" working on other changes, while
avoiding the need for a huge retrofit of existing code.
However, that compromise seems to be less appropriate for the subset of
linting rules related to code complexity in particular. That category of
rules typically imposes some arbitrary limit on a qualitative metric that
the linting tool can measure. These particular rules therefore have a
relatively broad scope and tend to require very disruptive changes to
existing code in order to resolve them.
This proposal aims to find a pragmatic path that will lead to a codebase
that _does_ conform to the complexity lint rules in the long run, but to
treat those improvements as a separate project in their own right rather
than as something we aim to gradually improve as part of other work.
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>
This continues the work of the last few commits, updating this RFC to
reflect the evolved design that's makes room for adding fully-dynamic
provider instance expansion in a later release.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Now that we have a prototype well understood, we can
better describe the technical challenges and implementation
flow
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
This is the beginnings of a proposed amendment to the previously-approved
RFC for static-eval-based provider expansion to incorporate the new
constraints discovered for RFC "Dynamic Provider Instances and Instance
Assignment".
This first draft of the changes focuses only on the "User Documentation"
portion to ensure that we have consensus on the intended user-facing
changes before worrying too much about the implementation details. A
subsequent commit will revise the implementation details once the new
version of the language design is settled.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
