- 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]
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
Previous to this commit, the Chainable class which is responsible for
iterating on the sequence of events in the intro Terraform animation,
was using setTimeout and thus could result in very messed up race
conditions when triggering physics changes.
This commit attaches the .wait timers to the Engine.render loop which
should enable everything to stay in sync.
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".
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.
The Terraform configuration syntax defines what arrays are.
Use the word array consistently throughout the documentation
instead of list.
The corresponding JSON datatype is called array as well, and
since the Terraform configuration syntax is interoperable with
JSON it makes sense to use the term array to describe them.
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.
Sander van Harmelen