* master:
providers/aws: Convert Launch Configurations to awslabs/aws-sdk-go
update CHANGELOG
terraform: test post state update is called
command: StateHook for continous state updates
terraform: more state tests, fix a bug
state: deep copies are required
terraform: make DeepCopy public
state/remote: increment serial properly
state: only change serial if changed
terraform: call the EvalUpdateStateHook strategically
terraform: PostStateUpdate hook and EvalUpdateStateHook
- Remove check on password for AWS RDS Instance
- Update documentation on AWS RDS Instance regarding DB Security Groups
- Change error handling to check error code from AWS API [ci skip]
The `SourceDestCheck` attribute can only be changed via
`ModifyInstance`, so the AWS instance resource's `Create` function calls
out to `Update` before it returns to take care of applying
`source_dest_check` properly.
The `Update` function originally guarded against unnecessary API calls
with `GetOk`, which worked fine until #993 when we changed the `GetOk`
semantics to no longer distinguish between "configured and zero-value"
and "not configured".
I attempted in #1003 to fix this by switching to `HasChange` for the
guard, but this does not work in the `Create` case.
I played around with a few different ideas, none of which worked:
(a) Setting `Default: true` on `source_dest_check' has no effect
(b) Setting `Computed: true` on `source_dest_check' and adding a `d.Set`
call in the `Read` function (which will initially set the value to `true`
after instance creation). I really thought I could get this to work,
but it results in the following:
```go
d.Get('source_dest_check') // true
d.HasChange('source_dest_check') // false
d.GetChange('source_dest_check') // old: false, new: false
```
I couldn't figure out a way of coherently dealing with that result, so I
ended up throwing up my hands and giving up on the guard altogether.
We'll call `ModifyInstance` more than we have to, but this at least
yields expected behavior for both Creates and Updates.
Fixes#1020
library.
This commit updates the Route 53 Zone resource to use AWS Labs aws-sdk-go
library instead of mitchellh/goamz.
- hard code us-east-1 for Route53 region, since it's a global endpoint
- add some units test for CleanZoneID
Unfortunately, the acceptance tests here were improperly passing, and
allowing Subnet updates on ELBs is not as straightfoward as simply
removing `ForceNew`.
Subnets on ELBs need to be managed by two explicit API calls:
* `AttachLoadBalancerToSubnets` - http://bit.ly/elbattachsubnet
* `DetachLoadBalanceFromSubnets` - http://bit.ly/elbdetachsubnet
We'll need to circle back and use these APIs to explicitly add support.
This fixes the failure of `TestAccAWSELB_AddSubnet` by removing the
test.
This reverts commit 61e91017be, reversing
changes made to 49b3afe452.
Was relying on old behavior of GetOk and therefore never properly seeing
a change from true -> false.
This fixes the acceptance test failure of
`TestAccAWSInstance_sourceDestCheck`.
The Mailgun provider was relying on an old behavior of
`ResourceData.Set` that would allow nested access to
maps. We now just build up our own maps like sane people.
AWS provides a single `BlockDeviceMapping` to manage three different
kinds of block devices:
(a) The root volume
(b) Ephemeral storage
(c) Additional EBS volumes
Each of these types has slightly different semantics [1].
(a) The root volume is defined by the AMI; it can only be customized
with `volume_size`, `volume_type`, and `delete_on_termination`.
(b) Ephemeral storage is made available based on instance type [2]. It's
attached automatically if _no_ block device mappings are specified, and
must otherwise be defined with block device mapping entries that contain
only DeviceName set to a device like "/dev/sdX" and VirtualName set to
"ephemeralN".
(c) Additional EBS volumes are controlled by mappings that omit
`virtual_name` and can specify `volume_size`, `volume_type`,
`delete_on_termination`, `snapshot_id`, and `encryption`.
After deciding to ignore root block devices to fix#859, we had users
with configurations that were attempting to manage the root block device chime
in on #913.
Terraform does not have the primitives to be able to properly handle a
single collection of resources that is partially managed and partially
computed, so our strategy here is to break out logical sub-resources for
Terraform and hide the BlockDeviceMapping inside the provider
implementation.
Now (a) is supported by the `root_block_device` sub-resource, and (b)
and (c) are still both merged together under `block_device`, though I
have yet to see ephemeral block devices working properly.
Looking into possibly separating out `ephemeral_block_device` and
`ebs_block_device` sub-resources as well, which seem like the logical
next step. We'll wait until the next big release for this, though, since
it will break backcompat.
[1] http://bit.ly/ec2bdmap
[2] http://bit.ly/instancestorebytypeFixes#913
Refs #858
Right now we yield a perpetual diff on ASGs because we're not reading
termination policies back out in the provider.
This depends on https://github.com/mitchellh/goamz/pull/218 and fixes
it.
An `InstanceDiff` will include `ResourceAttrDiff` entries for the
"length" / `#` field of maps. This makes sense, since for something like
`terraform plan` it's useful to see when counts are changing.
The `DiffFieldReader` was not taking these entries into account when
reading maps out, and was therefore incorrectly returning maps that
included an extra `'#'` field, which was causing all sorts of havoc
for providers (extra tags on AWS instances, broken google compute
instance launch, possibly others).
* fixes#914 - extra tags on AWS instances
* fixes#883 - general core issue sprouted from #757
* removes the hack+TODO from #757
This resource allows an existing Route Table to be assigned as the
"main" Route Table of a VPC. This means that the Route Table will be
used for any subnets within the VPC without an explicit Route Table
assigned [1].
This is particularly useful in getting an Internet Gateway in place as
the default for a VPC, since the automatically created Main Route Table
does not have one [2].
Note that this resource is an abstraction over an association and does not
map directly to a CRUD-able object in AWS. In order to retain a coherent
"Delete" operation for this resource, we remember the ID of the AWS-created
Route Table and reset the VPC's main Route Table to it when this
resource is deleted.
refs #843, #748
[1] http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html#RouteTableDetails
[2] http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html#Add_IGW_Routing
If map_public_ip_on_launch was not specified, AWS picks a default of
"0", which is different than the "" in the state file, triggerinng an
update each time. Mark that parameter as Computed, avoiding the update.
This is necessary to support creating parameter groups with parameters
that require a reboot, since the RDS API will return an error when
attempting to set those parameters with ApplyMethod "immediate".
If a subnet exists in the state file and a refresh is performed, the
read function for subnets would return an error. Now it updates the
state to indicate that the subnet no longer exists, so Terraform can
plan to recreate it.
with this commit, the google compute instance acceptance tests are
passing
- remove GOOGLE_CLIENT_FILE requirement from provider tests to finish
out #452
- skip extra "#" key that shows up in metadata maps, fixes#757 and
sprouts #883 to figure out core issue
- more verbose variablenames in metadata parsing, since it took me
awhile to grok and i thought there might have been a shadowing bug in
there for a minute. maybe someday when i'm a golang master i'll be
smart enough to be comfortable with one-char varnames. :)
Several of the arguments were optional, and if omitted, they are
calculated. Mark them as such in the schema to avoid triggering an
update.
Go back to storing the password in the state file. Without doing so,
there's no way for Terraform to know the password has changed. It should
be hashed, but then interpolating the password yields a hash instead of
the password.
Make the `name` parameter optional. It's not required in any engine, and
in some (MS SQL Server) it's not allowed at all.
Drop the `skip_final_snapshot` argument. If `final_snapshot_identifier`
isn't specified, then don't make a final snapshot. As things were, it
was possible to create a resource with neither of these arguments
specified which would later fail when it was to be deleted since the RDS
API requires exactly one of the two.
Resolves issue #689.
It’s now also possible to don’t give any rules, when the firewall is
configured with `managed = true`. This will in effect mean; make sure
no rules exist at all for the firewall.
These fixes are needed to make the provider work with master again.
These are still some issues, but they seem not to be related to the
provider, but the changes in `helper/schema`.
This goes for the normal firewall, the egress firewall and the network
ACL.
USE WITH CAUTION! When setting `managed = true` in your config, it
means it will delete all firewall rules that are not in your config, so
unknown to TF.
Also adding the new `cloudstack_egress_firewall` resource with this
commit and updating go-cloudstack to the latest API version (v4.4)
- 5.6.17 is no longer a valid mysql engine version, bumping to 5.6.21
- updating security_group_names assertion to match new set structure
introduce in #663
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.
Sander van Harmelen