The change in #10787 used flatmap.Expand to fix interpolation of nested
maps, but it broke interpolation of sets such that their elements were
not represented. For example, the expected string representation of a
splatted aws_network_interface.whatever.*.private_ips should be:
```
[{Variable (TypeList): [{Variable (TypeString): 10.41.17.25}]} {Variable (TypeList): [{Variable (TypeString): 10.41.22.236}]}]
```
But instead it became:
```
[{Variable (TypeList): [{Variable (TypeString): }]} {Variable (TypeList): [{Variable (TypeString): }]}]
```
This is because the expandArray function of expand.go treated arrays to
exclusively be lists, e.g. not sets. The old code used to match for
numeric keys, so it would work for sets, whereas expandArray just
assumed keys started at 0 and ascended incrementally. Remember that
sets' keys are numeric, but since they are hashes, they can be any
integer. The result of assuming that the keys start at 0 led to the
recursive call to flatmap.Expand not matching any keys of the set, and
returning nil, which is why the above example has nothing where the IP
addresses used to be.
So we bring back that matching behavior, but we move it to expandArray
instead. We've modified it to not reconstruct the data structures like
it used to when it was in the Interpolator, and to use the standard int
sorter rather than implementing a custom sorter since a custom one is no
longer necessary thanks to the use of flatmap.Expand.
Fixes#10908, and restores the viability of the workaround I posted in #8696.
Big thanks to @jszwedko for helping me with this fix. I was able to
diagnose the problem along, but couldn't fix it without his help.
The subsets for backend address pools and inbound nat rules weren't being hashed
properly as part of the ip_configuration hash which caused multiple
ip_configurations to be expanded and sent to the API with conflicting names
TF_ACC=1 go test ./builtin/providers/azurerm -v -run TestAccAzureRMNetworkInterface -timeout 120m
=== RUN TestAccAzureRMNetworkInterface_basic
--- PASS: TestAccAzureRMNetworkInterface_basic (160.24s)
=== RUN TestAccAzureRMNetworkInterface_disappears
--- PASS: TestAccAzureRMNetworkInterface_disappears (157.00s)
=== RUN TestAccAzureRMNetworkInterface_enableIPForwarding
--- PASS: TestAccAzureRMNetworkInterface_enableIPForwarding (156.86s)
=== RUN TestAccAzureRMNetworkInterface_multipleLoadBalancers
--- PASS: TestAccAzureRMNetworkInterface_multipleLoadBalancers (185.87s)
=== RUN TestAccAzureRMNetworkInterface_withTags
--- PASS: TestAccAzureRMNetworkInterface_withTags (1212.92s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm 1872.960s
This commit adds some basic tests for block device functionality. It also
expands the existing block device documentation as well references the
new "volume attach" resources for further block storage functionality.
This commit makes the openstack_blockstorage_volume resources better able
to handle volume creation errors upon resource creation. The cause of this
change is because there could be some storage backend error that happens
during storage provisioning that won't manifest in an "err" but will set
the volume's status to "error". We now check for a status of "error" and
propagate the error up the stack.
* Implementing Redis Cache
* Properties should never be nil
* Updating the SDK to 7.0.1
* Redis Cache updated for SDK 7.0.1
* Fixing the max memory validation tests
* Cleaning up
* Adding tests for Standard with Tags
* Int's -> Strings for the moment
* Making the RedisConfiguration object mandatory
* Only parse out redis configuration values if they're set
* Updating the RedisConfiguration object to be required in the documentaqtion
* Adding Tags to the Standard tests / importing excluding the redisConfiguration
* Removing support for import for Redis Cache for now
* Removed a scaling test
Fixes#4789
This improves the validation that valid provider aliases are used.
Previously, we required that provider aliases be defined in every module
they're used. This isn't correct because the alias may be used in a
parent module and inherited.
This removes that validation and creates the validation that a provider
alias must be defined in the used module or _any parent_. This allows
inheritance to work properly.
We've always had this type of validation for aliases because we believe
its a good UX tradeoff: typo-ing an alias is really painful, so we
require declaration of alias usage. It may add a small burden to
declare, but since relatively few aliases are used, it improves the
scenario where a user fat-fingers an alias name.
James Bardin