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
This commit adds further work to the OpenStack port resource:
* Makes relevant fields computed
* Adds state change functions
* Adds acceptance tests
* Adds Documentation
This commit cleans up areas that configure the image_id and image_name.
It enables the ability to not have to specify an image_id or image_name
when booting from a volume.
It also prevents Terraform from reporting an error when an image name is no
longer able to be resolved from an image ID. This usually happens when the
image has been deleted, but there are still running instances that were based
off of it.
The image_id and image_name parameters no longer immediately take a default
value from the OS_IMAGE_ID and OS_IMAGE_NAME environment variables. If no other
resolution of an image_id or image_name were found, then these variables will
be referenced. This further supports booting from a volume.
Finally, documentation was updated to take into account booting from a volume.
* 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
...
As of this commit this provider has only logical resources that allow
the creation of private keys, self-signed certs and certificate requests.
These can be useful when creating other resources that use TLS
certificates, such as AWS Elastic Load Balancers.
Later it could grow to include support for real certificate provision from
CAs using the LetsEncrypt ACME protocol, once it is stable.
Updates the docs and clarifies the usage of `do_token` variable.
I was experiencing an issue mentioned here https://github.com/hashicorp/terraform/issues/124 and so adding more docs should be helpful.
These new functions allow Terraform to be used for network address space
planning tasks, and make it easier to produce reusable modules that
contain or depend on network infrastructure.
For example:
- cidrsubnet allows an aws_subnet to derive its
CIDR prefix from its parent aws_vpc.
- cidrhost allows a fixed IP address for a resource to be assigned within
an address range defined elsewhere.
- cidrnetmask provides the dotted-decimal form of a prefix length that is
accepted by some systems such as routing tables and static network
interface configuration files.
The bulk of the work here is done by an external library I authored called
go-cidr. It is MIT licensed and was implemented primarily for the purpose
of using it within Terraform. It has its own unit tests and so the unit
tests within this change focus on simple success cases and on the correct
handling of the various error cases.
Fixing basic acceptance test.
Adding warning to website about mixed mode.
Adding exists to aws_route.
Adding acceptance test for changing destination_cidr_block.
* Update init docs to be correct, and provide an example.
* Update remote config docs to provide more details about the Consul
backend and to provide another example.
Since we merged this so that the community could collaborate on
improvements, I thought it would be prudent to inform potential users of
the status of the provider so they know what to expect.