also removed the notion of tags from the redshift security group and
parameter group documentation until that has been implemented
Redshift Cluster CRUD and acceptance tests
Removing the Acceptance test for the Cluster Updates. You cannot delete
a cluster immediately after performing an operation on it. We would need
to add a lot of retry logic to the system to get this test to work
Adding some schema validation for RedShift cluster
Adding the last of the pieces of a first draft of the Redshift work - this is the documentation
Changed the aws_redshift_security_group and aws_redshift_parameter_group
to remove the tags from the schema. Tags are a little bit more
complicated than originally though - I will revisit this later
Then added the schema, CRUD functionality and basic acceptance tests for
aws_redshift_subnet_group
Adding an acceptance test for the Update of subnet_ids in AWS Redshift Subnet Group
This action is almost exactly the same as creating a SimpleAD so we
reuse this resource and allow the user to specify the type when creating
the directory (ignoring the size if the type is MicrosoftAD).
Some error-checking was omitted.
Specifically, the cloudTrailSetLogging call in the Create function was
ignoring the return and cloudTrailGetLoggingStatus could crash on a
nil-dereference during the return. Fixed both.
Fixed some needless casting in cloudTrailGetLoggingStatus.
Clarified error message in acceptance tests.
Removed needless option from example in docs.
The default for `enable_logging`, which defines whether CloudTrail
actually logs events was originally written as defaulting to `false`,
since that's how AWS creates trails.
`true` is likely a better default for Terraform users.
Changed the default and updated the docs.
Changed the acceptance tests to verify new default behavior.
It's a bit confusing to have Terraform poll until instances come up on
ASG creation but not on update. This changes update to also poll if
min_size or desired_capacity are changed.
This changes the waiting behavior to wait for precisely the desired
number of instances instead of that number as a "minimum". I believe
this shouldn't have any undue side effects, and the behavior can still
be opted out of by setting `wait_for_capacity_timeout` to 0.
* master: (95 commits)
Update CHANGELOG.md
Update CHANGELOG.md
Update CHANGELOG.md
Update CHANGELOG.md
upgrade a warning to error
add some logging around create/update requests for IAM user
Update CHANGELOG.md
Update CHANGELOG.md
Build using `make test` on Travis CI
Update CHANGELOG.md
provider/aws: Fix error format in Kinesis Firehose
Update CHANGELOG.md
Changes to Aws Kinesis Firehouse Docs
Update CHANGELOG.md
modify aws_iam_user_test to correctly check username and path for initial and changed username/path
Update CHANGELOG.md
Update CHANGELOG.md
Prompt for input variables before context validate
Removing the AWS DBInstance Acceptance Test for withoutEngine as this is now part of the checkInstanceAttributes func
Making engine_version be computed in the db_instance provider
...
See #2911.
This adds a `name_prefix` option to `aws_launch_configuration` resources.
When specified, it is used instead of `terraform-` as the prefix for the
launch configuration. It conflicts with `name`, so existing
functionality is unchanged. `name` still sets the name explicitly.
Added an acceptance test, and updated the site documentation.
* pr-3707:
config updates for ElastiCache test
Removing the instance_type check in the ElastiCache cluster creation. We now allow the error to bubble up to the userr when the wrong instance type is used. The limitation for t2 instance types now allowing snapshotting is also now documented
Making the changes to the snapshotting for Elasticache Redis as per @catsby's findings
Added an extra test for the Elasticache Cluster to show that updates work. Also added some debugging to show that the API returns the Elasticache retention period info
When I was setting the update parameters for the Snapshotting, I didn't update the copy/pasted params
Adding the ability to specify a snapshot window and retention limit for Redis ElastiCache clusters
* master: (335 commits)
Update CHANGELOG.md
config: return to the go1.5 generated lang/y.go
Update CHANGELOG.md
Allow cluster name, not only ARN for aws_ecs_service
Update CHANGELOG.md
Add check errors on reading CORS rules
Update CHANGELOG.md
website: docs for null_resource
dag: use hashcodes to as map key to edge sets
Update CHANGELOG.md
Update CHANGELOG.md
Update CHANGELOG.md
Use hc-releases
provider/google: Added scheduling block to compute_instance
Use vendored fastly logo
Use releases for releases
Update CHANGELOG.md
Update CHANGELOG.md
Update vpn.tf
Update CHANGELOG.md
...
Fixing basic acceptance test.
Adding warning to website about mixed mode.
Adding exists to aws_route.
Adding acceptance test for changing destination_cidr_block.
aws_lb_cookie_stickiness_policy.elbland: Error creating LBCookieStickinessPolicy: ValidationError: Policy name cannot contain characters that are not letters, or digits or the dash.
The `ForceDelete` parameter was getting sent to the upstream API call,
but only after we had already finished draining instances from
Terraform, so it was a moot point by then.
This fixes that by skipping the drain when force_delete is true, and it
also simplifies the field config a bit:
* set a default of false to simplify the logic
* remove `ForceNew` since there's no need to replace the resource to
flip this value
* pull a detail comment from code into the docs
A "Layer" is a particular service that forms part of the infrastructure for
a set of applications. Some layers are application servers and others are
pure infrastructure, like MySQL servers or load balancers.
Although the AWS API only has one type called "Layer", it actually has
a number of different "soft" types that each have slightly different
validation rules and extra properties that are packed into the Attributes
map.
To make the validation rule differences explicit in Terraform, and to make
the Terraform structure more closely resemble the OpsWorks UI than its
API, we use a separate resource type per layer type, with the common code
factored out into a shared struct type.
"Stack" is the root concept in OpsWorks, and acts as a container for a number
of different "layers" that each provide some service for an application.
A stack isn't very interesting on its own, but it needs to be created before
any layers can be created.
* 'master' of github.com:hashicorp/terraform:
Update CHANGELOG.md
Changing the ElastiCache Cluster configuration_engine to be on the cluster, not on the cache nodes
Adding configuration endpoint to the elasticache cluster nodes
When launching a new RDS instance in a VPC-default AWS account, trying to control which VPC the new RDS instance lands in is not apparent from the parameters available.
The following works:
```
resource "aws_db_subnet_group" "foo" {
name = "foo"
description = "DB Subnet for foo"
subnet_ids = ["${aws_subnet.foo_1a.id}", "${aws_subnet.foo_1b.id}"]
}
resource "aws_db_instance" "bar" {
...
db_subnet_group_name = "${aws_db_subnet_group.foo.name}"
...
}
```
Hopefully this doc update will help others
AWS provides three different ways to create AMIs that each have different
inputs, but once they are complete the same management operations apply.
Thus these three resources each have a different "Create" implementation
but then share the same "Read", "Update" and "Delete" implementations.
The Elasticache API accepts a mixed-case subnet name on create, but
normalizes it to lowercase before storing it. When retrieving a subnet,
the name is treated as case-sensitive, so the lowercase version must be
used.
Given that case within subnet names is not significant, the new StateFunc
on the name attribute causes the state to reflect the lowercase version
that the API uses, and changes in case alone will not show as a diff.
Given that we must look up subnet names in lower case, we set the
instance id to be a lowercase version of the user's provided name. This
then allows a later Refresh call to succeed even if the user provided
a mixed-case name.
Previously users could work around this by just avoiding putting uppercase
letters in the name, but that is often inconvenient if e.g. the name is
being constructed from variables defined elsewhere that may already have
uppercase letters present.
* master: (84 commits)
provider/aws: Update to aws-sdk 0.9.0 rc1
use name instead of id - launch configs use the name and not ID
Fix typo on heroku_cert example
provider/aws: add value into ELB name validation message
tests: fix missed test update from last merge
update prevent_destroy error message
Update CHANGELOG.md
Update CHANGELOG.md
providers/aws: Update Launch Config. docs to detail naming and lifecycle recommendation
release: cleanup after v0.6.3
v0.6.3
Update CHANGELOG.md
core: fix deadlock when dependable node replaced with non-dependable one
tests: extract deadlock checking test helper
core: log every 5s while waiting for dependencies
Fixed indentation in a code sample
state/remote/s3: match with upstream changes
provider/aws: match with upstream changes
google: Add example of two-tier app
Updating Launch Config Docs for Name attribute
...
* upstream/master:
Update CHANGELOG.md
Update CHANGELOG.md
provider/aws: allow external ENI attachments
Update AWS provider documentation
docs/aws: Fix example of aws_iam_role_policy
provider/aws: S3 bucket test that should fail
provider/aws: Return if Bucket not found
Update CHANGELOG.md
Update CHANGELOG.md
helper/schema: record schema version when destroy fails
settings file is not required
provider/azure: Allow settings_file to accept XML string
add note to aws_iam_policy_attachment explaining its use/limitations
docs: clarify template_file path information
google: Sort resources by alphabet in docs
Support go get in go 1.5
Update CHANGELOG.md
aws_network_interface attachment block is not required
provider/aws: Fix issue in Security Group Rules where the Security Group is not found
This commit exports the `arn` as well as the `id`, since IAM
roles require the full resource name rather than just the table
name. I'd even be in favor or having `arn` as the `id` since the
<region, tablename> pair is the uniqueness constraint, but this
will keep backwards compatibility:
http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_CreateTable.html
* master: (720 commits)
Update CHANGELOG.md
Update CHANGELOG.md
dynamodb-local Update AWS config https://github.com/hashicorp/terraform/pull/2825#issuecomment-126353610
Make target_pools optional
Update CHANGELOG.md
code formatting
Update CHANGELOG.md
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
dynamodb-local Use ` instead of : to refer region to keep the consistency with the provider docs
dynamodb-local Update aws provider docs to include the `dynamodb_endpoint` argument
...
* 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
...
`aws_iam_access_key` resource is not supported `status` field.
Example from https://www.terraform.io/docs/providers/aws/r/iam_access_key.html:
resource "aws_iam_access_key" "lb" {
user = "${aws_iam_user.lb.name}"
status = "Active"
}
resource "aws_iam_user" "lb" {
name = "loadbalancer"
path = "/system/"
}
Result:
$ terraform plan
There are warnings and/or errors related to your configuration. Please
fix these before continuing.
Errors:
* aws_iam_access_key.lb: "status": this field cannot be set
* master:
Update CHANGELOG.md
Update CHANGELOG.md
Added affinity group resource.
update link to actually work
provider/azure: Fix SQL client name to match upstream
add warning message to explain scenario of conflicting rules
typo
remove debugging
Update CHANGELOG.md
provider/aws: Add docs for autoscaling_policy + cloudwatch_metric_alarm
provider/aws: Add autoscaling_policy
provider/aws: Add cloudwatch_metric_alarm
rename method, update docs
clean up some conflicts with
clean up old, incompatible test
update tests with another example
update test
remove meta usage, stub test
fix existing tests
Consider security groups with source security groups when hashing
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.
When a user tried to create an `aws_network_interface` resource without specifying the `private_ips` or `security_groups` attributes the API call to AWS would fail with a 500 HTTP error. Length checks have been put in place for both of these attributes before they are added to the `ec2.CreateNetworkInterfaceInput` struct.
Documentation was also added for the `aws_network_interface` resource.
When using `-1` for the protocol, both `from_port` and `to_port` must be `0`, or so says AWS thru Terraform:
```
* from_port (0) and to_port (65535) must both be 0 to use the the 'ALL' "-1" protocol!
```
db_security_group is only intended to be used in EC2-Classic Platform.
For DB instances in a VPC, we associate VPC security groups instead,
when declaring the db_instance resource.
* ctiwald/ct/fix-protocol-problem:
aws: Document the odd protocol = "-1" behavior in security groups.
aws: Fixup structure_test to handle new expandIPPerms behavior.
aws: Add security group acceptance tests for protocol -1 fixes.
aws: error on expndIPPerms(...) if our ports and protocol conflict.
On ASG creation, waits for up to 10m for desired_capacity or min_size
healthy nodes to show up in the group before continuing.
With CBD and proper HealthCheck tuning, this allows us guarantee safe
ASG replacement.
Other than the fact that "The the" doesn't really make any sense anywhere
that it's used in Terraform, they're a post-punk band from the UK.
Fixes "The The" so that they can get back to playing songs.
- Users
- Groups
- Roles
- Inline policies for the above three
- Instance profiles
- Managed policies
- Access keys
This is most of the data types provided by IAM. There are a few things
missing, but the functionality here is probably sufficient for 95% of
the cases. Makes a dent in #28.
* 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
- 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
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.
Paul Hinze