* 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.
If an attribute was not wholly known, helper/schema was skipping the
`validateType` function which (among other things) returned deprecation
messages. This PR checks for deprecation before returning when skipping
validateType.
The dependencies here are dated and are causing conflicts with the
ACME provider, namely the version of the top-level autorest package.
This explicitly updates the Azure SDK and autorest packages, with the
separately versioned sub-packages being added automatically.
You can signal the same information in `Read` with an empty ID if the object does not exist, Implementing `Exists` is not the only way to do so and in some providers is also not the preferred way.
Notable changes (from Terraform AWS Provider CHANGELOG):
```
NOTES:
* backend/s3: Region validation now automatically supports the new `me-south-1` Middle East (Bahrain) region. For AWS operations to work in the new region, the region must be explicitly enabled as outlined in the [previous new region announcement blog post](https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-hong-kong-region/). When the region is not enabled, the Terraform S3 Backend will return errors during credential validation (e.g. `error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid`).
* backend/s3: After this update, the AWS Go SDK will prefer credentials found via the `AWS_PROFILE` environment variable when both the `AWS_PROFILE` environment variable and the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables are statically defined. Previously the SDK would ignore the `AWS_PROFILE` environment variable, if static environment credentials were also specified. This is listed as a bug fix in the AWS Go SDK release notes.
ENHANCEMENTS:
* backend/s3: Add support for assuming role via web identity token via the `AWS_WEB_IDENTITY_TOKEN_FILE` and `AWS_ROLE_ARN` environment variables
* backend/s3: Support automatic region validation for `me-south-1`
BUG FIXES:
* backend/s3: Load credentials via the `AWS_PROFILE` environment variable (if available) when `AWS_PROFILE` is defined along with `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`
```
Updated via:
```
go get github.com/aws/aws-sdk-go@v1.21.7
go mod tidy
go mod vendor
```
Verification with this update:
```hcl
terraform {
backend "s3" {
bucket = "me-south-1-testing"
key = "test"
region = "me-south-1"
}
}
output "test" {
value = timestamp()
}
```
Outputs:
```
$ terraform apply
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
test = 2019-07-30T12:49:19Z
```
If the new region is not properly enabled for the account, errors like the below will be received:
```
$ terraform init
Initializing the backend...
Error: error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid.
```
To use this region before this update:
```hcl
terraform {
# ... potentially other configuration ...
backend "s3" {
# ... other configuration ...
region = "me-south-1"
skip_region_validation = true
}
}
```
Nil values were not previously expected during validation, but they can
appear in some situations with the new protocol. Add checks to prevent
using zero reflect.Values.
If there are unknowns, the block may have come from a dynamic
declaration, and we can't validate MinItems. Once the blocks are
expanded, we will get the full config for validation without any unknown
values.
If a block was defined via "dynamic", there will be only one block value
until the expansion is known. Since we can't detect dynamic blocks at
this point, don't verify MinItems while there are unknown values in the
config.
The decoder spec can also only check for existence of a block, so limit
the check to 0 or 1.
Chris Marchesi