* master: (86 commits)
providers/google: Fix reading account_file path
providers/google: Fix error appending
providers/google: Return if we could parse JSON
providers/google: Change account_file to JSON
providers/google: Default account_file* to empty
providers/google: Add account_file/account_file_contents ConflictsWith
providers/google: Document account_file_contents
providers/google: Use account_file_contents if provided
providers/google: Add account_file_contents to provider
Update CHANGELOG.md
Update CHANGELOG.md
use d.Id()
Update CHANGELOG.md
Update CHANGELOG.md
scripts: change website_push to push from HEAD
update analytics
core: fix crash on provider warning
provider/aws: Update source to comply with upstream breaking change
Update CHANGELOG.
provider/aws: Fix issue with IAM Server Certificates and Chains
...
Some AMIs have a RootDeviceName like "/dev/sda1" that does not appear as a
DeviceName in the BlockDeviceMapping list (which will instead have
something like "/dev/sda")
While this seems like it breaks an invariant of AMIs, it ends up working
on the AWS side, and AMIs like this are common enough that we need to
special case it so Terraform does the right thing.
Our heuristic is: if the RootDeviceName does not appear in the
BlockDeviceMapping, assume that the DeviceName of the first
BlockDeviceMapping entry serves as the root device.
fixes#2224
I snuck this in with #2263 because thought it was simply a stylistic
clarity thing, but it actually generates a resource-replacement-forcing
diff for existing resources that don't have this set in the config.
Definitely don't want that. :P
/cc @catsby
This is an iteration on the great work done by @dalehamel in PRs #2095
and #2109.
The core team went back and forth on how to best model Spot Instance
Requests, requesting and then rejecting a separate-resource
implementation in #2109.
After more internal discussion, we landed once again on a separate
resource to model Spot Instance Requests. Out of respect for
@dalehamel's already-significant donated time, with this I'm attempting
to pick up the work to take this across the finish line.
Important architectural decisions represented here:
* Spot Instance Requests are always of type "persistent", to properly
match Terraform's declarative model.
* The spot_instance_request resource exports several attributes that
are expected to be constantly changing as the spot market changes:
spot_bid_status, spot_request_state, and instance_id. Creating
additional resource dependencies based on these attributes is not
recommended, as Terraform diffs will be continually generated to keep
up with the live changes.
* When a Spot Instance Request is deleted/canceled, an attempt is made
to terminate the last-known attached spot instance. Race conditions
dictate that this attempt cannot guarantee that the associated spot
instance is terminated immediately.
Implementation notes:
* This version of aws_spot_instance_request borrows a lot of common
code from aws_instance.
* In order to facilitate borrowing, we introduce `awsInstanceOpts`, an
internal representation of instance details that's meant to be shared
between resources. The goal here would be to refactor ASG Launch
Configurations to use the same struct.
* The new aws_spot_instance_request acc. test is passing.
* All aws_instance acc. tests remain passing.
This landed in aws-sdk-go yesterday, breaking the AWS provider in many places:
3c259c9586
Here, with much sedding, grepping, and manual massaging, we attempt to
catch Terraform up to the new `awserr.Error` interface world.
Currently, we weren't correctly setting the ids, and are setting both
`security_groups` and `vpc_security_group_ids`. As a result, we really only use
the former.
We also don't actually update the latter in the `update` method.
This PR fixes both issues, correctly reading `security_groups` vs.
`vpc_security_group_ids` and allows users to update the latter without
destroying the Instance when in a VPC.
* master: (511 commits)
Update CHANGELOG.md
core: avoid diff mismatch on NewRemoved fields during -/+
Update CHANGELOG.md
update CHANGELOG
Fix minor error in index/count docs
terraform: remove debug
terraform: when pruning destroy, only match exact nodes, or exact counts
up version for dev
update CHANGELOG
terraform: prune tainted destroys if no tainted in state [GH-1475]
update CHANGELOG
config/lang: support math on variables through implicits
update CHANGELOG
update cHANGELOG
update cHANGELOG
providers/aws: set id outside if/esle
providers/aws: set ID after creation
core: remove dead code from pre-deposed refactor
website: update LC docs to note name is optional
security_groups field expects a list of Security Group Group Names, not IDs
...
Fixes#1409
Resource set hash calculation is a bit of a devil's bargain when it
comes to optional, computed attributes.
If you omit the optional, computed attribute from the hash function,
changing it in an existing config is not properly detected.
If you include the optional, computed attribute in the hash and do not
specify a value for it in the config, then you'll end up with a
perpetual, unresolvable diff.
We'll need to think about how to get the best of both worlds, here, but
for now I'm switching us to the latter and documenting the fact that
changing these attributes requires manual `terraform taint` to apply.
I was working on building a validation to check the user-provided
"device_name" for "root_block_device" on AWS Instances, when I realized
that if I can check it, I might as well just derive it automatically!
So that's what we do here - when you customize the details of the root
block device, device name is just comes from the selected AMI.
Instance block devices are now managed by three distinct sub-resources:
* `root_block_device` - introduced previously
* `ebs_block_device` - all additional ebs-backed volumes
* `ephemeral_block_device` - instance store / ephemeral devices
The AWS API support around BlockDeviceMapping is pretty confusing. It's
a single collection type that supports these three members each of which
has different fields and different behavior.
My biggest hiccup came from the fact that Instance Store volumes do not
show up in any response BlockDeviceMapping for any EC2 `Describe*` API
calls. They're only available from the instance meta-data service as
queried from inside the node.
This removes `block_device` altogether for a clean break from old
configs. New configs will need to sort their `block_device`
declarations into the three new types. The field has been marked
`Removed` to indicate this to users.
With the new block device format being introduced, we need to ensure
Terraform is able to properly read statefiles written in the old format.
So we use the new `helper/schema` facility of "state migrations" to
transform statefiles in the old format to something that the current
version of the schema can use.
Fixes#858
* master:
provider/aws: Fix encoding bug with AWS Instance
minor style cleanups
Tags Schema
Added Tagging
Added vpc refactor in aws sdk go
Removed additional variable for print, added for debugging
Using hashicorp/aws-sdk-go
Changed things around as suggested by @catsby
Refactor with Acceptance Tests
VPC Refactor
First refactor
Added Connection to config
Clint Shryock