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
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
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`.
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
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.
Clint Shryock