This repurposes the page that was previously about "terraform" blocks to
now be about "language" blocks instead.
This is the modern way to describe version compatibility constraints for
OpenTofu, though we retain some support for required_versions in
"terraform" blocks as a transitional aid for those who want to write
modules that can work with older versions of OpenTofu.
There were previously additional sections on this page discussing other
settings that can appear in "terraform" blocks, but they were essentially
just links to more detailed documentation elsewhere and so this reduces
all of that to just a single section that acknowledges that this block
type accepts other options and links to the relevant documentation for
each one. This structure matches the reality that "terraform" blocks are
just a dumping ground for a variety of tangentially-related settings, and
that we're intending to gradually replace all of the settings in there
with brand-agnostic alternatives in future releases.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The recent addition of "aws login" to AWS CLI finally gives a user-friendly
best practice way to acquire AWS credentials for use in interactive
workflows. Combined with the pre-existing support for authenticating using
JSON web tokens (by "web identity", as AWS calls it), there's no longer any
good reason for most users of this backend to explicitly configure AWS
credentials.
Now that OpenTofu itself supports using credentials issued by "aws login",
this reorganizes our documentation to begin with opinionated
recommendations for how to provide credentials for the S3 backend in both
interactive and non-interactive settings, and explicitly documents the
inline static configuration settings as an absolute last resort not
recommended in any cases.
This new documentation also includes links to the relevant parts of the
AWS CLI documentation, since there's a lot of extra detail there which may
be useful for someone trying to debug why their setup isn't working.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We got this new functionality from an upgrade of the upstream cty library,
but we didn't update the docs to mention it.
The examples in this doc were also evidently generated with a much older
version of OpenTofu's predecessor, because the illustrated output was not
shown as a quoted string. The example output now matches how the current
version of "tofu console" would describe these results.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Over time the discussion about "lifecycle" blocks in the documentation
became confusing because the docs originally written for managed resource
lifecycle got partially generalized for resources of other modes and for
module calls, even though each of those has a completely different
lifecycle and thus a different set of lifecycle settings.
This is a first pass at trying to reorganize that so that the "lifecycle"
page is really just an index of all of the different kinds of lifecycle
block that exist in the language, while the main documentation for each
use of that block type now belongs with the documentation of the block
it's nested within.
While working on this I also found that there was some duplication inside
the "data sources" page where the same information was described multiple
times, and a few other cases where things had become inconsistent over
time. This also includes a little extra content to try to clarify the
difference between managed, data, and ephemeral resources and to make it
explicit that the "Resources" section is focused only on managed resources
because that is the primary resource mode.
As usual there's lots more that could be done here -- this documentation
has gradually evolved over time and is full of weird quirks due to that
evolution -- but I decided to draw a line here so that the diff wouldn't
get too large.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This uses the same auth package as the newly-rewritten Azure State
Backend, so many of the properties and environment variables are the
same. I have put this through both the compliance test as well as built
the binary and run some end-to-end tests, and found that it
appropriately uses the Azure key as expected.
Signed-off-by: Larry Bordowitz <laurence.bordowitz@gmail.com>
As of go-getter v1.8.0, which we already upgraded in an earlier commit,
the S3 "getter" now uses the AWS SDK's default credentials chain
configuration and so follows the same set of credentials-searching
strategies that AWS CLI and other AWS SDK applications would follow.
We learned this only after having already merged that upgrade, so this is
a retroactive documentation and changelog update to describe the change.
Since go-getter is now delegating this whole question to the AWS SDK, our
future upgrades of the AWS SDK will automatically adopt any upstream
changes to the default credentials chain and so our documentation about
this is now more general than before: the intention is that our users can
generally assume that OpenTofu should support everything that is documented
as supported for the AWS CLI, instead of us listing out an explicit search
sequence that will be long and inevitably become outdated again.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a first draft of documentation describing our new capability to
treat artifacts in OCI Distribution repositories as a new kind of remote
module package.
This documentation includes both some caller-focused documentation that
extends our existing "Module Sources" page, and some documentation intended
more for the author of a module package describing how they could publish
their package as an OCI artifact that OpenTofu will accept.
As usual, we'll continue to refine this documentation based on feedback
during the prerelease period and beyond.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
