We originally included this warning because the go-cty-yaml module wasn't
yet stable and it was also not extensively tested so it wasn't yet clear
if its behavior would need to change in some less common cases we hadn't
tested so far.
However, go-cty-yaml had its v1.0.0 release some time ago and is now
committed to preserving its current Marshal output unless it is found to
be non-compliant with the YAML 1.2 specification. This doc change means
that Terraform's yamlencode is now adopting a similar posture:
- The exact style details produced by the function for a particular input
are now frozen. It'll change only if we find that the function is
producing output that isn't valid per the YAML spec.
- If someone finds a YAML parser that cannot parse what yamlencode
produces but what it produces is valid per the YAML 1.2 spec, we'll
expect the parser to be corrected to better support the spec rather
than changing the yamlencode output.
There may be pragmatic exceptions if we encounter a situation we cannot
anticipate yet, but the above will be our general rule. This is really
just a specialization of the spirit of the v1.x Compatibility Promises,
tailored specifically to this function.
This is a complement to "timestamp" and "timeadd" which allows
establishing the ordering of two different timestamps while taking into
account their timezone offsets, which isn't otherwise possible using the
existing primitives in the Terraform language.
The existing description for the '-' symbol as use in format() stated that the result would padded spaces to the left. When tested in via 'terraform console' using format("%-10.1f", 3) the result was "3.0 "
Terraform v1.1.7
Fix output in `toset`
```
toset(["a", "b", 3])
toset([
"3",
"a",
"b",
])
```
This is the actual output from the tf console, using Terraform v1.1.5 on windows_amd64
The `substr` function allows the `length` parameter to be longer than the remaining characters in the input after the offset. This is useful for when you want to truncate a string to a maximum number of characters. However, the documentation isn't clear on this so I had to do a test deployment to confirm the behaviour after finding the behaviour in an old issue https://github.com/hashicorp/terraform/issues/15751
This paragraph is trying to say that try only works for dynamic errors and
not for errors that are _not_ based on dynamic decision-making in
expressions.
I'm not sure if this typo was always here or if it was mistakenly "corrected"
at some point, but either way the word "probably" changes the meaning
of this sentence entirely, making it seem like Terraform is hedging
the likelihood of a problem rather than checking exactly for one.
Go 1.17 includes a breaking change to both net.ParseIP and net.ParseCIDR
functions to reject IPv4 address octets written with leading zeros.
Our use of these functions as part of the various CIDR functions in the
Terraform language doesn't have the same security concerns that the Go
team had in evaluating this change to the standard library, and so we
can't justify an exception to our v1.0 compatibility promises on the same
sort of security grounds that the Go team used to justify their
compatibility exception.
For that reason, we'll now use our own fork of the Go library functions
which has the new check disabled in order to preserve the prior behavior.
We're taking this path, rather than pre-normalizing the IP address before
calling into the standard library, because an additional normalization
layer would be entirely new code and additional complexity, whereas this
fork is relatively minor in terms of code size and avoids any significant
changes to our own calls to these functions.
Thanks to the Kubernetes team for their prior work on carving out a subset
of the "net" package for their similar backward-compatibility concern.
Our "ipaddr" package here is a lightly-modified fork of their fork, with
only the comments changed to talk about Terraform instead of Kubernetes.
This fork is not intended for use in any other future feature
implementations, because they wouldn't be subject to the same
compatibility constraints as our existing functions. We will use these
forked implementations for new callers only if consistency with the
behavior of the existing functions is a key requirement.
