* provider/openstack: LoadBalancer Security Groups
This commit adds the ability to specify security groups on a loadbalancer
resource.
* provider/openstack: LoadBalancer Security Groups Refactor
Moving common security group code into a dedicated function.
If an error occurred which prevented the lb sub resources being written to state
then the next apply would fail as the resources would already exist in the API.
go test -c ./builtin/providers/azurerm -o ./builtin/providers/azurerm/test-azurerm
TestAccAzureRMLoadBalancerBackEndAddressPool_reapply
TestAccAzureRMLoadBalancerBackEndAddressPool_removal
TestAccAzureRMLoadBalancerNatPool_basic
TestAccAzureRMLoadBalancerBackEndAddressPool_basic
TestAccAzureRMLoadBalancerNatRule_basic
TestAccAzureRMLoadBalancerNatPool_reapply
TestAccAzureRMLoadBalancerNatPool_removal
TestAccAzureRMLoadBalancerNatPool_update
TestAccAzureRMLoadBalancerProbe_basic
TestAccAzureRMLoadBalancerNatRule_removal
TestAccAzureRMLoadBalancerNatRule_update
TestAccAzureRMLoadBalancerNatRule_reapply
TestAccAzureRMLoadBalancerProbe_removal
TestAccAzureRMLoadBalancerProbe_reapply
TestAccAzureRMLoadBalancerProbe_update
TestAccAzureRMLoadBalancerRule_basic
TestAccAzureRMLoadBalancerRule_inconsistentReads
TestAccAzureRMLoadBalancerRule_removal
TestAccAzureRMLoadBalancerProbe_updateProtocol
TestAccAzureRMLoadBalancer_basic
TestAccAzureRMLoadBalancerRule_update
TestAccAzureRMLoadBalancerRule_reapply
TestAccAzureRMLoadBalancer_frontEndConfig
TestAccAzureRMLoadBalancer_tags
Documentation for the `aws_route_table` data source mentions that it supports a route table `id` as an argument, however it was missing from the actual provider code.
Adds in the missing provider code, adds a test, and updates the documentation to use `rtb_id` as the argument, instead of the more ambiguous `id`.
A VPC's main route table has an implicit subnet association, not an explicit subnet association. This caused a Terraform panic when using the `data_source_aws_route_table` resource to query the main route table for a VPC.
This fixes the Terraform panic, and allows the data lookup to complete successfully. Also added an acceptance test to verify the bugfix.
Fixes: #11134
The second step of the `TestAccDigitalOceanDroplet_ResizeWithOutDisk` acceptance test was regularly failing. Upon investigation it was found that the second step's Terraform configuration had omitted the `user_data` parameter, thus forcing Terraform to create a new droplet resource instead of updating the current resource.
```
-/+ digitalocean_droplet.foobar
disk: "20" => "<computed>"
image: "centos-7-x64" => "centos-7-x64"
ipv4_address: "138.197.0.55" => "<computed>"
ipv4_address_private: "" => "<computed>"
ipv6_address: "" => "<computed>"
ipv6_address_private: "" => "<computed>"
locked: "false" => "<computed>"
name: "foo" => "foo"
region: "nyc3" => "nyc3"
resize_disk: "true" => "false"
size: "512mb" => "1gb"
ssh_keys.#: "1" => "1"
ssh_keys.0: "5770472" => "5770472"
status: "active" => "<computed>"
user_data: "foobar" => "" (forces new resource)
vcpus: "1" => "<computed>"
```
This fixes the acceptance test by adding the missing `user_data` parameter.
request_path had Computed enabled which prevented updating it to an empty value
TF_ACC=1 go test ./builtin/providers/azurerm -v -run TestAccAzureRMLoadBalancerProbe -timeout 120m
=== RUN TestAccAzureRMLoadBalancerProbe_basic
--- PASS: TestAccAzureRMLoadBalancerProbe_basic (119.63s)
=== RUN TestAccAzureRMLoadBalancerProbe_removal
--- PASS: TestAccAzureRMLoadBalancerProbe_removal (122.50s)
=== RUN TestAccAzureRMLoadBalancerProbe_update
--- PASS: TestAccAzureRMLoadBalancerProbe_update (129.98s)
=== RUN TestAccAzureRMLoadBalancerProbe_duplicate
--- PASS: TestAccAzureRMLoadBalancerProbe_duplicate (115.22s)
=== RUN TestAccAzureRMLoadBalancerProbe_updateProtocol
--- PASS: TestAccAzureRMLoadBalancerProbe_updateProtocol (127.25s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm 614.657s
As brought up in #10174, our update_strategy property for instance group
managers in GCP would always be set to "RESTART" on read, even if the
user asked for them to be "NONE" in the config.
This adds a test to ensure that the user wishes were respected, which
fails until we check for update_strategy in the ResourceData before we
update it within the Read function. Because the update_strategy property
doesn't map to anything in the API, we never need to read it from
anywhere but the config, which means the ResourceData should be
considered authoritative by the time we get to the Read function.
The fix for this was provided by @JDiPierro in #10198 originally, but
was missing tests, so it got squashed into this.
* provider/aws: Save disabled ELB accesslogs to state
Save any explicitly disabled access_log to state. Do not save disabled
access_logs if they are not in the configuration.
* test that fails on master
Adds validation for the `type` parameter of an `aws_route53_record` resource.
This will allow Terraform to catch any user errors of a `type` parameter during a `terraform plan` instead of during a `terraform apply`.
Fixes: #11114
* provider/aws: New Resource - aws_codedeploy_deployment_config
* provider/aws: Adding acceptance tests for new
aws_codedeploy_deployment_config resource
* provider/aws: Documentation for the aws_codedeploy_deployment_config resource
* Update codedeploy_deployment_config.html.markdown
Paul Stack