terraform run
Fixes#3550
The simple fix here was to check if the Resource was new (to set the
value the first time) then check it has changed each time
I was able to see from the TF log the following:
```
Config
resource "aws_vpc" "foo" {
cidr_block = "10.10.0.0/16"
}
resource "aws_subnet" "foo" {
cidr_block = "10.10.1.0/24"
vpc_id = "${aws_vpc.foo.id}"
}
resource "aws_instance" "foo" {
ami = "ami-4fccb37f"
instance_type = "m1.small"
subnet_id = "${aws_subnet.foo.id}"
source_dest_check = false
disable_api_termination = true
}
```
No longer caused any Modifying source_dest_check entries in the LOG
* provider/aws: Add docs for Default Route Table
* add new default_route_table_id attribute, test to VPC
* stub
* add warning to docs
* rough implementation
* first test
* update test, add swap test
* fix typo
We con no longer copy an InstanceState via a simple
dereference+assignment because of the mutex which can't be copied. This
adds a set method to properly set all field from another InstanceState,
and take the appropriate locks while doing so.
Fixes#8468
If a user wished to bump the `engine_version` of an RDS instance,
Terraform was not sending `allow_major_version_upgrade` to the API
*unless* that value also changed at the same time. This caused the
following error from RDS API:
```
* aws_db_instance.bar: Error modifying DB Instance
* tf-20160825101420910562798obb: InvalidParameterCombination: The
* AllowMajorVersionUpgrade flag must be present when upgrading to a new
* major version.
status code: 400, request id: 20e36364-6ab0-11e6-b794-51f12f4135f1
```
This change will always send the `allow_major_version_upgrade` flag to
the API when the `engine_version` changes.
This still relies on the user setting the correct value i.e. if they are
upgrading from postgres 0.4.7 -> 9.5.2 then the config will need to set
the `allow_major_version_upgrade` flag to be `true`
* provider/aws: add `aws_ssm_document` resource
* provider/aws: Changes to `aws_ssm_document` post code review
The changes are things like using d.Id rather than d.Get("name").(string)
and errwrap.Wrapf rather than fmt.Errorf
* Fix crash when reading VPC Peering Connection options.
This resolves the issue introduced in #8310.
Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
* Do not de-reference values when using Set().
Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
* provider/aws: Update VPC Peering connect accept/request attributes
* change from type list to type set
* provider/aws: Update VPC Peering accept/requst options, tests
* errwrap some things
This commit is changing the `volumes` block from being computed to non-computed.
This change makes the Terraform configuration the source of truth about volumes
attached to the instance and therefore is able to correctly detect when a user
detaches a volume during an update.
One thing to be aware of is that if a user attached a volume out of band of an
instance controlled by Terraform, that volume will be detached upon the next
apply. The best thing to do is add a `volume` entry in the instance's
configuration of any volumes that were attached out of band.
This commit also explicitly detaches volumes from an instance before the
instance terminates. Most Block Storage volume drivers account for this
scenario internally, but there are a few that don't. This change is to support
those that don't.
In addition, when volumes are read by the instance, volumes configured in the
Terraform configuration are the source of truth. Previously, a call was being
made to OpenStack to provide the list of attached volumes.
It also adds a few new tests and fixes existing tests for various volume
attach-related scenarios.
Add locks to the state structs to handle concurrency during the graph
walks. We can't embed the mutexes due to serialization constraints when
communicating with providers, so expose the Lock/Unlock methods
manually.
Use copystructure.LockedCopy to ensure locks are honored.
Allows specifying `LD_FLAGS` during development builds.
```
$ LD_FLAGS="-linkmode=external" make dev
```
Since the version of DTrace on macOS Sierra (On the public beta's at least) has been updated, this allows DTrace to run on Terraform during development/debugging.
```
$ sudo dtrace -n 'pid$target::main.main:entry' -c "terraform apply"
dtrace: description 'pid$target::main.main:entry' matched 1 probe
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
foo = bar
dtrace: pid 23096 has exited
CPU ID FUNCTION:NAME
2 265673 main.main:entry
```
Also redirects the `@which stringer` command inside the `generate` Makefile target to `/dev/null` so we stop echoing the path to the `stringer` binary on every call to `generate`.
Paul Stack