Fixes#7543 where creating a CloudWatch Group, then deleting it from the
console will cause no action on refresh / plan
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSCloudWatchLogGroup_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSCloudWatchLogGroup_ -timeout 120m
=== RUN TestAccAWSCloudWatchLogGroup_importBasic
--- PASS: TestAccAWSCloudWatchLogGroup_importBasic (18.10s)
=== RUN TestAccAWSCloudWatchLogGroup_basic
--- PASS: TestAccAWSCloudWatchLogGroup_basic (17.34s)
=== RUN TestAccAWSCloudWatchLogGroup_retentionPolicy
--- PASS: TestAccAWSCloudWatchLogGroup_retentionPolicy (49.81s)
=== RUN TestAccAWSCloudWatchLogGroup_multiple
--- PASS: TestAccAWSCloudWatchLogGroup_multiple (23.74s)
=== RUN TestAccAWSCloudWatchLogGroup_disappears
--- PASS: TestAccAWSCloudWatchLogGroup_disappears (15.78s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 124.789s
```
The PR that was merged to add `keep_on_destroy` was showing a green
build so was merged but that build happened before another merge adding
another parameter to the tests
FYI @dkalleg - fixes#7169
Had to make some changes to this resource. Params were not being set in
the Read func - also added a statefunc to the IPAddressAllocation as
that was coming back in a different case to how we were sending it. We
need to treat that property as case-insensitive
```
% make testacc TEST=./builtin/providers/azurerm TESTARGS='-run=TestAccAzureRMPublicIpStatic_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMPublicIpStatic_ -timeout 120m
=== RUN TestAccAzureRMPublicIpStatic_importBasic
--- PASS: TestAccAzureRMPublicIpStatic_importBasic (128.06s)
=== RUN TestAccAzureRMPublicIpStatic_basic
--- PASS: TestAccAzureRMPublicIpStatic_basic (126.25s)
=== RUN TestAccAzureRMPublicIpStatic_withTags
--- PASS: TestAccAzureRMPublicIpStatic_withTags (145.99s)
=== RUN TestAccAzureRMPublicIpStatic_update
--- PASS: TestAccAzureRMPublicIpStatic_update (192.32s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm
592.648s
```
- Include new option in file provisioner. Now content or source can be
provided. Content will create a temp file and copy there the contents.
- Later that file will be used as source.
- Include test to check that changes are working correctly.
The template resources don't actually need to retain any state, so they
are good candidates to be data sources.
This includes a few tweaks to the acceptance tests -- now configured to
run as unit tests -- since it seems that they have been slightly broken
for a while now. In particular, the "update" cases are no longer tested
because updating is not a meaningful operation for a data source.
As part of evaluating a variable block, there is a pass made on unknown
keys setting them to the config.DefaultVariableValue sentinal value.
Previously this only took into account one level of nesting and assumed
all values were strings.
This commit now traverses the unknown keys via lists and maps and sets
unknown map keys surgically.
Fixes#7241.
Part of the interpolation walk is to detect keys which involve computed
values and therefore cannot be resolved at this time. The interplation
walker keeps sufficient state to be able to populate the ResourceConfig
with a slice of such keys.
Previously they didn't take slice indexes into account, so in the
following case:
```
"services": []interface{}{
map[string]interface{}{
"elb": "___something computed___",
},
map[string]interface{}{
"elb": "___something else computed___",
},
map[string]interface{}{
"elb": "not computed",
},
}
```
Unknown keys would be populated as follows:
```
services.elb
services.elb
```
This is not sufficient information to be useful, as it is impossible to
distinguish which of the `services.elb`s are unknown vs not.
This commit therefore retains the slice indexes as part of the key for
unknown keys - producing for the example above:
```
services.0.elb
services.1.elb
```
The reproduction of issue #7421 involves a list of maps being passed to
a module, where one or more of the maps has a value which is computed
(for example, from another resource). There is a failure at the point of
use (via lookup interpolation) of the computed value of the form:
```
lookup: lookup failed to find 'elb' in:
${lookup(var.services[count.index], "elb")}
```
Where 'elb' is the key of the map.
Paul Hinze