This allows child processes launched with local-exec to contribute to the same trace that OpenTofu started.
Signed-off-by: ogormans-deptstack <sean.ogorman@deptagency.com>
We inherited this "compatibility promises" document from our predecessor
as part of the fork, but have now come to realize that the specific set of
platforms it committed to support had become quite stale over time: macOS
support for x64 is phasing out in favor of Apple Silicon, and 32-bit CPU
architectures are no longer commonly used.
In preparation for some anticipated future changes to platform support,
this revises the "Supported Platforms" section of our compatibility
promises so that it no longer commits to any specific platforms and instead
documents that we intend to provide two minor release period's worth of
advance notice for removing support for any platform that is currently
supported. This is a more sustainable compromise that will allow us to
respond to ongoing changes in which platforms are commonly used in our
community, and which platforms are supported well by the dependencies that
OpenTofu relies on.
This also proactively switches from listing darwin_amd64 to darwin_arm64
and removes the commitment to support linux_arm. We do not intend to
immediately stop testing on and building for those two platforms, but we
do expect to phasing them out under the revised version of this policy
in future releases and so this update serves as part of our initial
communication about that future change.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
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>
At some point after this documentation was originally written the schema
structure grew to include the possibility of structural attribute types,
represented using "nested_type" instead of "type" in the attribute
definition, but it seems that the documentation was not updated to mention
that.
This is just a minimal extra note about that focused mainly on just
acknowledging that this possibility exists at all, in case anyone is
relying on these docs to build something to parse this format. It would
probably be helpful to expand both this and the existing documentation to
specify the format more precisely, but my focus here is just on quickly
filling in this missing piece so that the documentation is complete, even
if not detailed and precise.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
By design the "-raw" option to "tofu output" writes the literal output
value directly to stdout without any quoting or escaping, and so it's
risky to use it with an output value that could be controlled by an
attacker when stdout is a terminal.
This risk is inherent in the purpose of this option and is part of the
reason why this is not the default behavior (OpenTofu returns a quoted
representation of an output string by default) so here we just make that
risk explicit in the documentation, in the hope that operators will use
this operation mindfully.
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>
