When DeleteInternetGateway is successful it returns a nil error value.
However, for a nil error value, the RetryFunc returns an error yielding a
unnecessary second call to DeleteInternetGateway in the retry logic.
The logic works because DeleteInternetGateway eventually returns an ec2.Error
with error code InvalidInternetGatewayID.NotFound since the internet gateway
has been deleted in the previous call. The return value of nil breaks the
retry logic and the deletion is deemed successful.
Fix the unnecessary second call to DeleteInternetGateway by short circuiting
with a nil error value when deletion of the internet gateway is successful on
the first try.
Add an acceptance test for internet gateway deletion and remove unreachable
code while here.
Update the Google Compute Engine provider to add support for service
accounts on `google_compute_instance`. Both gcloud shorthand (`compute-ro`,
`storage-ro`, etc.) and OAuth2 API endpoints are supported.
This feature is currently limited to a single service account (supporting
multiple scopes) and an automatically-generated service account email.
If not suppling the `availability_zones`, they will be computed
(meaning an update/refresh will retrieve the info and update the values
to the state file).
So without the `Computed = true` the diff will always flag this as a
change, even when it’s not.
Some instance types have a block device by default. So when selecting
such an instance type, you will not set a config for the block device,
but the update/refresh func will notice one and update the state
nonetheless.
So in those cases the `block_device` becomes a `computed` field.
1. The schema contained a few fields that where not marked as
`computed`, while they were updated inside the resource.
2. While updating the `volume_size` it was doing so with a `string`,
but in the schema this field is set as `int`.
3. The set func for calculating the hashes for the `block` set items,
also used computed values to calculate the hash. As these values will
not be in the config, but only in the state, this will always show as a
diff. The solution is to only use the fields that aren’t computed in
order to get consistent hashes.
These where all issues before, but weren’t visible as such. All should
be good again now.
For now this only supports importing a key pair (by specifying a
public_key) property. In the future it'd be fairly trivial to support
key pair creation, with the private key returned as a computed property.
In real world usage you'd probably want to provide that public_key
property via a variable rather than hard-coding it into a terraform
config that'd end up in source control.
Fixes the following vet report:
builtin/providers/mailgun/resource_mailgun_domain_test.go:73: arg DomainResp.Domain.Wildcard for printf verb %s of wrong type: bool
Fixes the following vet reports:
builtin/providers/heroku/resource_heroku_app.go:192: arg vs for printf verb %s of wrong type: bool
builtin/providers/heroku/resource_heroku_app.go:198: arg vs for printf verb %s of wrong type: bool
Fixes the following vet reports:
builtin/providers/aws/resource_aws_network_acl.go:191: wrong number of args for format in Errorf call: 2 needed but 3 args
builtin/providers/aws/resource_aws_network_acl.go:264: wrong number of args for format in Errorf call: 1 needed but 2 args
builtin/providers/aws/resource_aws_network_acl.go:268: wrong number of args for format in Errorf call: 1 needed but 2 args
builtin/providers/aws/resource_aws_network_acl.go:286: arg m[to_port].(int) for printf verb %s of wrong type: int
builtin/providers/aws/resource_aws_network_acl_test.go:277: arg r.NetworkAcls for printf verb %s of wrong type: []github.com/mitchellh/goamz/ec2.NetworkAcl
builtin/providers/aws/resource_aws_subnet_test.go:21: arg v.MapPublicIpOnLaunch for printf verb %s of wrong type: bool
There was an error in the goamz package the prevented updating the
availability zones correctly. So PR #181 should be merged before this
one can be merged…
By using a set for the availability zones, you can use things like
`availability_zones = ["${aws_instance.web.*.availability_zone}"]`
where is very likely multiple of the same zones will be added to the
set. If you use a list here, the list will say it’s changed (even if
you add the same zone) which will force a new resource.
Before all providers were using the helper.Schema approach the helper
function had these names. Now they all use names consistent with the Go
naming conventions except for these last few…
The resource is build so it can attach and detach the Internet Gateway
from a VPC, but as the schema has `Required` and `ForceNew` both set
to `true` for the vpc_id field it will never use these capabilities.
This is a refactored solution for PR #616. Functionally this is still
the same change, but it’s implemented a lot cleaner with less code and
less changes to existing parts of TF.
Running the tests without these changes results in this error first:
```
--- FAIL: TestAccAWSNetworkAclsOnlyIngressRulesChange (24.92 seconds)
testing.go:121: Step 0 error: Check failed: Invalid number of ingress
entries found; count = %!s(int=3)
FAIL
exit status 1
FAIL github.com/hashicorp/terraform/builtin/providers/aws 24.974s
```
And after fixing that one you also get a few unexpected values due to
an expected order mismatch between the items in the set versus the
items in the config.
Those are also fixed, so the test is passing now.
Of course not all resources are covered by this first release, but
there should be enough resources available to handle most common
operations.
Tests and docs are included.
If a droplet's image slug is empty and its image id is empty, then the
image attribute should be empty, so we may assign from either. So it is
unnecessary to check if the image id is empty.
* remove unnecessary check for emptiness of image id
* reverse order of the conditions for assigning the image attribute,
with the default case (using the slug) first, and the fallback case
(using the id) second
This makes testing easier and gives you a way to configure the provider
using env variables. It also makes the provider more inline following
the TF 0.2 approach.
Otherwise it is impossible to get simple configurations with the
"default" routing table, which is only the "local" route.
The following contents of main.tf expose the bug, and boots an instance
fine after this patch is applied:
variable aws_access_key {}
variable aws_secret_key {}
variable aws_ubuntu_ami {}
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
region = "us-east-1"
}
resource "aws_vpc" "default" {
cidr_block = "10.0.0.0/20"
}
resource "aws_route_table" "private" {
vpc_id = "${aws_vpc.default.id}"
# Note the lack of "route" sub-key here.
}
resource "aws_subnet" "private" {
vpc_id = "${aws_vpc.default.id}"
cidr_block = "10.0.1.0/24"
}
resource "aws_route_table_association" "private" {
subnet_id = "${aws_subnet.private.id}"
route_table_id = "${aws_route_table.private.id}"
}
# Demonstrate an instance can be booted fine in this fashion.
resource "aws_instance" "sample" {
ami = "${var.aws_ubuntu_ami}"
instance_type = "t2.micro"
subnet_id = "${aws_subnet.private.id}"
}
terraform.tfvars for completeness:
aws_access_key = "..."
aws_secret_key = "..."
# A public Trusty AMI
aws_ubuntu_ami = "ami-9aaa1cf2"
Sander van Harmelen