These existing upstream cty functions allow matching strings against
regular expression patterns, which can be useful if you need to consume
a non-standard string format that Terraform doesn't (and can't) have a
built-in function for.
This interface is meant to replace the following ones (in use by some providers):
- httpclient.UserAgentString() (e.g. AzureRM, Google)
- terraform.UserAgentString (e.g. OpenStack, ProfitBricks)
- terraform.VersionString (e.g. AWS, AzureStack, DigitalOcean, Kubernetes)
This also proposes the initial UA string to be set to
HashiCorp Terraform/X.Y.Z (+https://www.terraform.io)
Create the missing modules in the state when moving resources to a
module that doesn't yet exist. This allows for refactoring of
configuration into new modules, without having to create dummy resources
in the module before the "state mv" operations.
* lang/funcs: lookup() can work with maps of lists, maps and objects
lookup() can already handle aribtrary objects of (whatever) and should
handle maps of (whatever) similarly.
Sometimes HTTP requests are buried inside third-party libraries where we
can't otherwise access their request method/URL, so this ensures we'll
always have at least a record of the fact that a request happened, even if
there's no other logging for why it did.
We only include the method and URL here under the assumption that
secret keys and other particularly sensitive information will not appear
there, in line with usual best-practices.
This is just a wholesale move of the CLI configuration types and functions
from the main package into its own package, leaving behind some type
aliases and wrappers for now to keep existing callers working.
This commit alone doesn't really achieve anything, but in future commits
we'll expand the functionality in this package.
We added the csvdecode function originally with the intent of it being
used with for_each, but because csvdecode was released first we had a
section in its documentation warning about the downsides of using it with
"count", since that seemed like something people would be likely to try.
With resource "for_each" now merged, we can replace that scary section
with a more positive example of using these two features together.
We still include a paragraph noting that "count" _could_ be used here, but
with a caution against doing so. This is in the hope of helping users
understand the difference between these two patterns and why for_each is
the superior choice for most situations.
Alex Pilon