this datasource allows terraform to work with externally modified state, e.g.
when you're using an ECS service which is continously updated by your CI via the
AWS CLI.
right now you'd have to wrap terraform into a shell script which looks up the
current image digest, so running terraform won't change the updated service.
using the aws_ecs_container_definition data source you can now leverage
terraform, removing the wrapper entirely.
Since this resource produces a list it feels more intuitive to give its
attribute a plural name, and since the noun "instance" already means
something specific in the AWS provider that doesn't apply here we use
"names" to indicate that these are availability zone names.
Also includes updating the docs to not show a dynamic count example for
now, since we don't support that yet.
false
Fixes#7035
A known issue in Terraform means that d.GetOk() on a bool which is false
will mean it doesn't get evaulated. Therefore, when people set
publicly_accessible to false, it will never get evaluated on the Create
We are going to make it default to false now
The documentation wording implies that in all cases you have to manually accept peering requests. This change is intended to clarify where this is required. The documentation also separates between "basic usage" and "basic usage with tags", but the expanded usage didn't actually provide much additional useful information. Expanded a bit to show the use of auto_accept since both VPCs are created by the content and to show setting the Name tag for proper display in the console.
resize
When resizing a DO droplet, you can only increase the size not
descrease. If you try and go down in size, the API will return this
error:
```
* digitalocean_droplet.foobar: Error resizing droplet (17090364):
POST https://api.digitalocean.com/v2/droplets/17090364/actions:
422 Size can not decrease size of Droplet's disk image
```
Since the custom_configuration_parameters can't take dots, we cannot
set 'disk.EnableUUID'. This adds a parameter for this options that gets
added to a configSpec. This option causes the vm to mount disks by uuid
on the guest OS.
* Adding debug functionality to log debug api calls
* adding debug and refactoring tests
* more tweaks with tests
* updating documentation
* more refactoring of tests
* working through factor for testing
* removing logging that displays username and password
* more work on getting tests stable
The example is referencing a non-existent variable, `allocation_id`, within the `aws_eip` resource. I believe this should actually be `aws_eip.example.id` instead of `aws_eip.example.allocation_id`.
Add the iam_arn attribute to aws_cloudfront_origin_access_identity,
which computes the IAM ARN for a certain CloudFront origin access
identity.
This is necessary because S3 modifies the bucket policy if CanonicalUser
is sent, causing spurious diffs with aws_s3_bucket resources.
This brings over the work done by @apparentlymart and @radeksimko in
PR #3124, and converts it into a data source for the AWS provider:
This commit adds a helper to construct IAM policy documents using
familiar Terraform concepts. It makes Terraform-style interpolations
easier and resolves the syntax conflict between Terraform interpolations
and IAM policy variables by changing the latter to use &{...} for its
interpolations.
Its use is completely optional and users are free to go on using literal
heredocs, file interpolations or whatever else; this just adds another
option that fits more naturally into a Terraform config.
...as this will hopefully clue people in that this function will indeed
work to manipulate ipv6 networks.
Not that I completely spaced on that for quite some time, or anything
like that.
Nope, not me. Not at all.
This data source allows one to look up the most recent AMI for a specific
set of parameters, much like aws ec2 describe-images in the AWS CLI.
Basically a refresh of hashicorp/terraform#4396, in data source form.
* Add per user, role and group policy attachment
* Add docs for new IAM policy attachment resources.
* Make policy attachment resources manage only 1 entity<->policy attachment
* provider/aws: Tidy up IAM Group/User/Role attachments
This commit adds a data source with a single list, `instance` for the
schema which gets populated with the availability zones to which an
account has access.
Allow a cloud admin to target a specific tenant in which to allocate
a floating IP. This is useful when the cloud admin does not want to
delegate network privileges to the tenants or various Q&A scenarios.
resource
We had a line on the Update func that said:
```
Hash key can only be specified at creation, you cannot modify it.
```
The resource has now been changed to ForceNew on the hashkey
```
aws_dynamodb_table.demo-user-table: Refreshing state... (ID: Users)
aws_dynamodb_table.demo-user-table: Destroying...
aws_dynamodb_table.demo-user-table: Destruction complete
aws_dynamodb_table.demo-user-table: Creating...
aws_dynamodb_table.demo-user-table: Creation complete
```
Changed schema type for disks to support dynamic non-ordered disk
swapping. All Disk attributes have been made non ForceNew since
any changes should be handled in the upgrade() function.
Added 'name' attribute to disks to act as a unique
identifier for when users request for new disks. It is also used as
the filename for the new disk. Templates are considered immutable.
The openstack_networking_subnet_v2 resource was originally designed
to have DHCP disabled by default; however, a bug in the original
implementation caused DHCP to always be enabled and never be
disabled. This bug was fixed in #6052.
Recent discussions have shown that users prefer if DHCP is enabled
by default. This commit implements makes the change.
When stage_name is not passed to the resource
aws_api_gateway_deployment a terraform apply will fail. This is
because the stage_name is required and not optional.
* Grafana provider
* grafana_data_source resource.
Allows data sources to be created in Grafana. Supports all data source
types that are accepted in the current version of Grafana, and will
support any future ones that fit into the existing structure.
* Vendoring of apparentlymart/go-grafana-api
This is in anticipation of adding a Grafana provider plugin.
* grafana_dashboard resource
* Website documentation for the Grafana provider.
* provider/datadog Update go-datadog-api.
* provider/datadog Add support for "require_full_window" and "locked".
* provider/datadog Update tests, update doco, gofmt.
* provider/datadog Add options to update resource.
* provider/datadog "require_full_window" defaults to True, "locked" to False. Use
those initial values as the starting configuration.
* provider/datadog Update notify_audit tests to use the default value for
testAccCheckDatadogMonitorConfig and a custom value for
testAccCheckDatadogMonitorConfigUpdated.
This catches a situation where the code ignores setting the option on creation,
and the update function merely asserts the default value, versus actually changing
the value.
`azurerm_storage_account` access keys
Please note that we do NOT have the ability to manage the access keys -
we are just getting the keys that the account creates for us. To manage
the keys, you would need to use the azure portal still
As a first example of a real-world data source, the pre-existing
terraform_remote_state resource is adapted to be a data source. The
original resource is shimmed to wrap the data source for backward
compatibility.
As requested in #4822, add support for a KMS Key ID (ARN) for Db
Instance
```
make testacc TEST=./builtin/providers/aws
TESTARGS='-run=TestAccAWSDBInstance_kmsKey' 2>~/tf.log
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSDBInstance_kmsKey -timeout 120m
=== RUN TestAccAWSDBInstance_basic
--- PASS: TestAccAWSDBInstance_basic (587.37s)
=== RUN TestAccAWSDBInstance_kmsKey
--- PASS: TestAccAWSDBInstance_kmsKey (625.31s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 1212.684s
```
Auto-generating an Instance Template name (or just its suffix) allows the
create_before_destroy lifecycle option to function correctly on the
Instance Template resource. This in turn allows Instance Group Managers
to be updated without being destroyed.
This introduces the terraform state list command to list the resources
within a state. This is the first of many state management commands to
come into 0.7.
This is the first command of many to come that is considered a
"plumbing" command within Terraform (see "plumbing vs porcelain":
http://git.661346.n2.nabble.com/what-are-plumbing-and-porcelain-td2190639.html).
As such, this PR also introduces a bunch of groundwork to support
plumbing commands.
The main changes:
- Main command output is changed to split "common" and "uncommon"
commands.
- mitchellh/cli is updated to support nested subcommands, since
terraform state list is a nested subcommand.
- terraform.StateFilter is introduced as a way in core to filter/search
the state files. This is very basic currently but I expect to make it
more advanced as time goes on.
- terraform state list command is introduced to list resources in a
state. This can take a series of arguments to filter this down.
Known issues, or things that aren't done in this PR on purpose:
- Unit tests for terraform state list are on the way. Unit tests for the
core changes are all there.
This changes the representation of maps in the interpolator from the
dotted flatmap form of a string variable named "var.variablename.key"
per map element to use native HIL maps instead.
This involves porting some of the interpolation functions in order to
keep the tests green, and adding support for map outputs.
There is one backwards incompatibility: as a result of an implementation
detail of maps, one could access an indexed map variable using the
syntax "${var.variablename.key}".
This is no longer possible - instead HIL native syntax -
"${var.variablename["key"]}" must be used. This was previously
documented, (though not heavily used) so it must be noted as a backward
compatibility issue for Terraform 0.7.
This introduces the terraform state list command to list the resources
within a state. This is the first of many state management commands to
come into 0.7.
This is the first command of many to come that is considered a
"plumbing" command within Terraform (see "plumbing vs porcelain":
http://git.661346.n2.nabble.com/what-are-plumbing-and-porcelain-td2190639.html).
As such, this PR also introduces a bunch of groundwork to support
plumbing commands.
The main changes:
- Main command output is changed to split "common" and "uncommon"
commands.
- mitchellh/cli is updated to support nested subcommands, since
terraform state list is a nested subcommand.
- terraform.StateFilter is introduced as a way in core to filter/search
the state files. This is very basic currently but I expect to make it
more advanced as time goes on.
- terraform state list command is introduced to list resources in a
state. This can take a series of arguments to filter this down.
Known issues, or things that aren't done in this PR on purpose:
- Unit tests for terraform state list are on the way. Unit tests for the
core changes are all there.
* core: Add support for marking outputs as sensitive
This commit allows an output to be marked "sensitive", in which case the
value is redacted in the post-refresh and post-apply list of outputs.
For example, the configuration:
```
variable "input" {
default = "Hello world"
}
output "notsensitive" {
value = "${var.input}"
}
output "sensitive" {
sensitive = true
value = "${var.input}"
}
```
Would result in the output:
```
terraform apply
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
notsensitive = Hello world
sensitive = <sensitive>
```
The `terraform output` command continues to display the value as before.
Limitations: Note that sensitivity is not tracked internally, so if the
output is interpolated in another module into a resource, the value will
be displayed. The value is still present in the state.
* provider/fastly: Add support for Conditions for Fastly Services
Docs here:
- https://docs.fastly.com/guides/conditions/
Also Bump go-fastly version for domain support in S3 Logging
* New top level AWS resource aws_eip_association
* Add documentation for aws_eip_association
* Add tests for aws_eip_association
* provider/aws: Change `aws_elastic_ip_association` to have computed
parameters
The AWS API was send ing more parameters than we had set. Therefore,
Terraform was showing constant changes when plans were being formed
* Adding private ip address reference
* adding private ip address reference
* Updating the docs.
* Removing optional attrib from private_ip_address
Removing optional attribute from private_ip_address, this element is only being used in the read.
* Selecting the first element instead of using a loop for now.
Change this to a loop when https://github.com/Azure/azure-sdk-for-go/issues/259 is fixed
Added the hosted_zone_id attribute, which aliases to the Route 53
zone ID that can be used to route Alias Resource Record Sets to.
This fixeshashicorp/terraform#6489.
adminPassword
Reports from issues showed the following errors:
```
{
"error": {
"code": "InvalidParameter",
"target": "adminPassword",
"message": "The supplied password must be
between 6-72 characters long and must
satisfy at least 3 of password complexity
requirements from the following: \r\n1)
Contains an uppercase character\r\n2)
Contains a lowercase character\r\n3)
Contains a numeric digit\r\n4) Contains a
special character."
}
}
```
This commit adds some documentation for the adminPassword complexity
requirements
ssh_keys were throwing an error similar to this:
```
* azurerm_virtual_machine.test: [DEBUG] Error setting Virtual Machine
* Storage OS Profile Linux Configuration: &errors.errorString{s:"Invalid
* address to set: []string{\"os_profile_linux_config\", \"0\",
* \"ssh_keys\"}"}
```
This was because of nesting of Set within a Set in the schema. By
changing this to a List within a Set, the schema works as expected. This
means we can now set SSH Keys on VMs. This has been tested using a
remote-exec and a connection block with the ssh key
```
azurerm_virtual_machine.test: Still creating... (2m10s elapsed)
azurerm_virtual_machine.test (remote-exec): Connected!
azurerm_virtual_machine.test (remote-exec): CONNECTED!
```
Change the AWS DB Instance to now include the DB Option Group param. Adds a test to prove that it works
Add acceptance tests for the AWS DB Option Group work. This ensures that Options can be added and updated
Documentation for the AWS DB Option resource
automated_snapshot_retention_period
The default value for `automated_snapshot_retention_period` is 1.
Therefore, it can be included in the `CreateClusterInput` without
needing to check that it is set.
This was actually stopping people from setting the value to 0 (disabling
the snapshots) as there is an issue in `d.GetOk()` evaluating 0 for int
Just wanted to call out that the CLI prompts for values for unset variables instead of an error. Guessing that was an enhancement somewhere along the line and just didn't get updated in the docs.
Here is an example that will setup the following:
+ An SSH key resource.
+ A virtual server resource that uses an existing SSH key.
+ A virtual server resource using an existing SSH key and a Terraform managed SSH key (created as "test_key_1" in the example below).
(create this as sl.tf and run terraform commands from this directory):
```hcl
provider "softlayer" {
username = ""
api_key = ""
}
resource "softlayer_ssh_key" "test_key_1" {
name = "test_key_1"
public_key = "${file(\"~/.ssh/id_rsa_test_key_1.pub\")}"
# Windows Example:
# public_key = "${file(\"C:\ssh\keys\path\id_rsa_test_key_1.pub\")}"
}
resource "softlayer_virtual_guest" "my_server_1" {
name = "my_server_1"
domain = "example.com"
ssh_keys = ["123456"]
image = "DEBIAN_7_64"
region = "ams01"
public_network_speed = 10
cpu = 1
ram = 1024
}
resource "softlayer_virtual_guest" "my_server_2" {
name = "my_server_2"
domain = "example.com"
ssh_keys = ["123456", "${softlayer_ssh_key.test_key_1.id}"]
image = "CENTOS_6_64"
region = "ams01"
public_network_speed = 10
cpu = 1
ram = 1024
}
```
You'll need to provide your SoftLayer username and API key,
so that Terraform can connect. If you don't want to put
credentials in your configuration file, you can leave them
out:
```
provider "softlayer" {}
```
...and instead set these environment variables:
- **SOFTLAYER_USERNAME**: Your SoftLayer username
- **SOFTLAYER_API_KEY**: Your API key
IPv6 support added.
We support 1 IPv6 address per interface. It seems like the vSphere SDK supports more than one, since it's provided as a list.
I can change it to support more than one address. I decided to stick with one for now since that's how the configuration parameters
had been set up by other developers.
The global gateway configuration option has been removed. Instead the user should specify a gateway on NIC level (ipv4_gateway and ipv6_gateway).
For now, the global gateway will be used as a fallback for every NICs ipv4_gateway.
The global gateway configuration option has been marked as deprecated.
this implements two new resource types:
* openstack_networking_secgroup_v2 - create a neutron security group
* openstack_networking_secgroup_rule_v2 - create a newutron security
group rule
Unlike their nova counterparts the neutron security groups allow a user
to specify the target tenant_id allowing a cloud admin to create per
tenant resources.
* Adding File Resource for vSphere provider
Allows for file upload to vSphere at specified location. This also
includes update for moving or renaming of file resources.
* Ensuring required parameters are provided
This commit adds several example uses of the
openstack_compute_instance_v2 resource. It also makes a clarification
about booting from volumes and image ids/names.
* command/fmt: Document -diff doesn't disable -write
As noted in hashicorp/terraform#6343, this description misleadingly
suggested that the `-diff` option disables the `-write` option.
This isn't the case and because of the default options (described in
c753390) the behaviour of `terraform fmt -diff` is actually the same as
`terraform fmt -write -list -diff`.
Replace the "instead of rewriting" description to clarify that.
Documentation in hcl/fmtcmd is corrected in hashicorp/hcl#117 but it's not
really necessary to bump the dependency version.
* command/fmt: Show flag defaults in help text
These were documented on the website but not in the `-help` text. This
should help to clarify that you need to pass `-list=false -write=false
-diff` if you only want to see diffs.
Accordingly I've replaced the word "disabled" with "always false" in the
STDIN special cases so that it matches the terminology used in the defaults
and better indicates that it is overridden.
NB: The 3x duplicated defaults and documentation makes me feel uneasy once
again. I'm not sure how to solve that, though.
* Fix headers and header anchor tags
The markdown parser already generates unique ids for header elements by
downcasing all of the words and replacing spaces with hyphens. Knowing
this, we can take the code blocks out of the headers and use the
generated ids as the link targets.
Aside: I tried to see if there was a standard way of documenting
subresources, but couldn't really find one. Both the aws_elb and
aws_instance resources seem to just say "documented below" without a
link. Then the relevant section is just a new paragraph with a list of
arguments.
* Reformat long lines
I find 80 character lines and whitespaces make the lists much easier to
read :)
* Remove extraneous <a> tags for header anchor tags
Now that middleman generates anchor tags for headers automagically, we
don't need to have blank <a> tags for anchor links to use.
* provider/fastly: Add S3 Log Streaming to Fastly Service
Adds streaming logs to an S3 bucket to Fastly Service V1
* provider/fastly: Bump go-fastly version for domain support in S3 Logging
This change adds the support for the proxied configuration option for a
record which enables origin protection for CloudFlare records.
In order to do so the golang library needed to be changed as the old did
not support the option and was using and outdated API version.
Open issues which ask for this (#5049, #3805).
User may specify a vmdk in their disk definition.
The options size, template, and vmdk are considered
to be mutually exclusive. User may also set whether each disk
associated with the vm should try to boot after creation.
Todo: Enforce mutual exclusivity, validate the bootable_vmdk_path
Just saying `id` is ambiguous, it could be interpreted as the resource ID which will fail with the follow error: `CertificateNotFound: Server Certificate not found for the key: <id>`. The AWS documentation states that the ssl certificate id parameter must be the ARN.
Previously we linked to the whole request body definition for valid values of `runtime`.
Now we link directly to the docs for `Runtime`, which will hopefully make it easier to find the valid values.
This fixes#4570.
Official OpenStack clients commonly support specifing a client
certificate/key to enable SSL client authentication when communicating
with OpenStack services. This patch enables such feature in Terraform
with new parameters and environment variables:
* 'cert' provider parameter or OS_CERT env variable to specify client
certificate file,
* 'key' provider parameter or OS_KEY env variable to specify client
certificate private key file.
It can come in handy to be able to mount ISOs programmatically.
For instance if you're developing a custom appliance (that automatically installs itself on the hard drive volume)
that you want to automatically test on every successful build (given the ISO is uploaded to the vmware datastore).
There are probably lots of other reasons for using this functionality.
* provider/aws: Fix hashing on CloudFront certificate parameters
Adding necessary type assertion to values on the viewer_certificate hash
function to ensure that certain fields are indeed not zero string
values, versus simply zero interface{} values (aka nil, as is such for a
map[string]interface{}).
* provider/aws: CloudFront complex structure error handling
Handle errors better on calls to d.Set() in the
aws_cloudfront_distribution, namely in flattenDistributionConfig(). Also
caught a bug in the setting of the origin attribute, was incorrectly
attempting to set origins.
* provider/aws: Pass pointers to set CloudFront primitives
Change a few d.Set() for primitives in aws_cloudfront_distribution and
aws_cloudfront_origin_access_identity to use the pointer versus a
dereference.
* docs: Fix CloudFront examples formatting
Ran each example thru terraform fmt to fix indentation.
* provider/aws: Remove delete retention on CloudFront tests
To play better with Travis and not bloat the test account with disabled
distributions.
Disable-only functionality has been retained - one can enable it with
the TF_TEST_CLOUDFRONT_RETAIN environment variable.
* provider/aws: CloudFront delete waiter error handling
The call to resourceAwsCloudFrontDistributionWaitUntilDeployed() on
deletion of CloudFront distributions was not trapping error messages,
causing issues with waiter failure.
* provider/fastly: Add support for managing Headers
Adds support for managing Headers in a Fastly configuration.
* update acc test
* update website with example of adding a header block
* provider/aws: Default Network ACL resource
Provides a resource to manage the default AWS Network ACL. VPC Only.
* Remove subnet_id update, mark as computed value. Remove extra tag update
* refactor default rule number to be a constant
* refactor revokeRulesForType to be revokeAllNetworkACLEntries
Refactor method to delete all network ACL entries, regardless of type. The
previous implementation was under the assumption that we may only eliminate some
rule types and possibly not others, so the split was necessary.
We're now removing them all, so the logic isn't necessary
Several doc and test cleanups are here as well
* smite subnet_id, improve docs
According to the libpq documentation, "prefer" is the default in the
underlying library and so setting a different default in the Terraform
layer would be a breaking change for existing users of this provider
whose servers do not have TLS correctly configured.
The docs now link to the libpq manual's discussion of the security
implications of each of the ssl_mode options, so the user can understand
the limitations of the "prefer" default and can make an informed decision
about which setting is appropriate for their situation.
This introduces a provider for Cobbler. Cobbler manages bare-metal
deployments and, to some extent, virtual machines. This initial
commit supports the following resources: distros, profiles, systems,
kickstart files, and snippets.
* CloudFront implementation v3
* Update tests
* Refactor - new resource: aws_cloudfront_distribution
* Includes a complete re-write of the old aws_cloudfront_web_distribution
resource to bring it to feature parity with API and CloudFormation.
* Also includes the aws_cloudfront_origin_access_identity resource to generate
origin access identities for use with S3.
* provider/aws: CodeDeploy Deployment Group Triggers
- Create a Trigger to Send Notifications for AWS CodeDeploy Events
- Update aws_codedeploy_deployment_group docs
* Refactor validateTriggerEvent function and test
- also rename TestAccAWSCodeDeployDeploymentGroup_triggerConfiguration test
* Enhance existing Deployment Group integration tests
- by using built in resource attribute helpers
- these can get quite verbose and repetitive, so passing the resource to a function might be better
- can't use these (yet) to assert trigger configuration state
* Unit tests for conversions between aws TriggerConfig and terraform resource schema
- buildTriggerConfigs
- triggerConfigsToMap
We have a curtesy function in place allowing you to specify both a
`name` of `ID`. But in order for the graph to be build correctly when
you recreate or taint stuff that other resources depend on, we need to
reference the `ID` and *not* the `name`.
So in order to enforce this and by that help people to not make this
mistake unknowingly, I deprecated all the parameters this allies to and
changed the logic, docs and tests accordingly.
Added the ability to set the "privacy" of a github_team resource so all teams won't automatically set to private.
* Added the privacy argument to github_team
* Refactored parameter validation to be general for any argument
* Updated testing
This commit enables the ability to authenticate to OpenStack by way
of a Keystone Token. Tokens can provide a way to use Terraform and
OpenStack with an expiring, temporary credential. The token will need
to be generated out of band from Terraform.
On creating CloudWatch metric alarms, I need to get the HealthCheckId dimension. Reference would be useful.
```
dimensions {
"HealthCheckId" = "${aws_route53_health_check.foo.id}"
}
```
This commit adds a no_gateway attribute. When set, the subnet will
not have a gateway. This is different than not specifying a
gateway_ip since that will cause a default gateway of .1 to be used.
This behavior mirrors the OpenStack Neutron command-line tool.
Fixes#6031
When calling AssociateAddress, the PrivateIpAddress parameter must be
used to select which private IP the EIP should associate with, otherwise
the EIP always associates with the _first_ private IP.
Without this parameter, multiple EIPs couldn't be assigned to a single
ENI. Includes covering test and docs update.
Fixes#2997
GitHub really doesn't like when you make the H lowercase, it violates
their brand guidelines and they won't help promote anything that doesn't
use the capital H.
* update docs on required parameter for api_gateway_integration
This parameter was required for lambda integration.
Otherwise,
` Error creating API Gateway Integration: BadRequestException: Enumeration value for HttpMethod must be non-empty`
* documentation: Including the AWS type on the api_gateway_integration docs
Documentation for `aws_cloudwatch_event_target` to warn that in order to be
able to have your AWS Lambda function or SNS topic invoked by a CloudWatch
Events rule, you must setup the right permissions
using `aws_lambda_permission` or `aws_sns_topic.policy`
It turns out all other providers use `ip_address` where the CloudStack
provider uses `ipaddress`. To make this more consistent this PR
deprecates `ipaddress` and adds `ip_address` where needed…
This new resource is an alternative to consul_keys that manages all keys
under a given prefix, rather than arbitrary single keys across the entire
store.
The key advantage of this resource over consul_keys is that it is able to
detect and delete keys that are added outside of Terraform, whereas
consul_keys is only able to detect changes to keys it is explicitly
managing.
This brings across the following resources for Triton from the
joyent/triton-terraform repository, and converts them to the canonical
Terraform style, introducing Terraform-style documentation and
acceptance tests which run against the live API rather than the local
APIs:
- triton_firewall_rule
- triton_machine
- triton_key
This brings across the following resources for Triton from the
joyent/triton-terraform repository, and converts them to the canonical
Terraform style, introducing Terraform-style documentation and
acceptance tests which run against the live API rather than the local
APIs:
- triton_firewall_rule
- triton_machine
- triton_key
Needed to truncate the identifier for SQL Server engines to keep it at
max 15 chars per the docs. Not a full UUID going into it, but should be
"unique enough" to not matter in practice.
Modified the basic test to use the generated value. Other tests are
still working w/ explicitly specified identifiers.
Previously this resource managed the set of keys as a whole rather than
the individual keys, and so it was unable to recognize when a particular
managed key is removed and delete just that one key from Consul.
Here this is addressed by recognizing that each key actually has its own
lifecycle, and detecting when individual keys are added and removed
without replacing the entire consul_keys instance.
Additionally this restores the behavior of updating the "value" attribute
on read, but restricts it only to blocks that already had a value so as
to avoid the quirkiness seen previously when we updated blocks that were
intended to be read-only. Updating the value is important now, because we
rely on this to detect and repair discrepancies between values stored in
Consul and values given in the configuration.
This change produces a change in the handling of the "delete" attribute.
Before it was considered only when the entire consul_keys resource was
deleted, but now it is considered also when a particular key block is
removed from within a resource.
This adds support for Elastic Beanstalk Applications, Configuration Templates,
and Environments.
This is a combined work of @catsby, @dharrisio, @Bowbaq, and @jen20
These options don't make sense when passing STDIN. `-write` will raise an
error because there is no file to write to. `-list` will always say
`<standard input>`. So disable whenever using STDIN, making the command
much simpler:
cat main.tf | terraform fmt -
So that you can do automatic formatting from an editor. You probably want to
disable the `-write` and `-list` options so that you just get the
re-formatted content, e.g.
cat main.tf | terraform fmt -write=false -list=false -
I've added a non-exported field called `input` so that we can override this
for the tests. If not specified, like in `commands.go`, then it will default
to `os.Stdin` which works on the command line.
The most common usage usage will be enabling the `-write` and `-list`
options so that files are updated in place and a list of any modified files
is printed. This matches the default behaviour of `go fmt` (not `gofmt`). So
enable these options by default.
This does mean that you will have to explicitly disable these if you want to
generate valid patches, e.g. `terraform fmt -diff -write=false -list=false`
This uses the `fmtcmd` package which has recently been merged into HCL. Per
the usage text, this rewrites Terraform config files to their canonical
formatting and style.
Some notes about the implementation for this initial commit:
- all of the fmtcmd options are exposed as CLI flags
- it operates on all files that have a `.tf` suffix
- it currently only operates on the working directory and doesn't accept a
directory argument, but I'll extend this in subsequent commits
- output is proxied through `cli.UiWriter` so that we write in the same way
as other commands and we can capture the output during tests
- the test uses a very simple fixture just to ensure that it is working
correctly end-to-end; the fmtcmd package has more exhaustive tests
- we have to write the fixture to a file in a temporary directory because it
will be modified and for this reason it was easier to define the fixture
contents as a raw string
these changes were added to reflect what was required to run the tutorial on my local machine. Below is my context for the above changes:
```shell
[2016-03-04T18:22:44] micperez in terraform_test
λ terraform remote config -backend-config="name=puhrez/getting-started"
missing 'access_token' configuration or ATLAS_TOKEN environmental variable
If the error message above mentions requiring or modifying configuration
options, these are set using the `-backend-config` flag. Example:
-backend-config="name=foo" to set the `name` configuration
[2016-03-04T18:23:27] micperez in terraform_test
λ export ATLAS_TOKEN=<REDACTED>
[2016-03-04T18:24:12] micperez in terraform_test
λ terraform remote config -backend-config="name=puhrez/getting-started"
Remote state management enabled
Remote state configured and pulled.
[2016-03-04T18:24:16] micperez in terraform_test
λ terraform push -name="puhrez/getting-started"
An error has occurred while archiving the module for uploading:
error detecting VCS: no VCS found for path: /Users/micperez/code/terraform_test
[2016-03-04T18:24:39] micperez in terraform_test
λ git init
Initialized empty Git repository in /Users/micperez/code/terraform_test/.git/
[2016-03-04T18:25:09] micperez in terraform_test [git:master]
λ terraform push -name="puhrez/getting-started"
An error has occurred while archiving the module for uploading:
error getting git commit: exit status 128
stdout:
stderr: fatal: bad default revision 'HEAD'
[2016-03-04T18:25:12] micperez in terraform_test [git:master]
λ git status
On branch master
Initial commit
Untracked files:
(use "git add <file>..." to include in what will be committed)
.terraform/
example.tf
terraform.tfstate.backup
nothing added to commit but untracked files present (use "git add" to track)
[2016-03-04T18:25:17] micperez in terraform_test [git:master]
λ git add example.tf
[2016-03-04T18:25:24] micperez in terraform_test [git:master]
λ git commit -m "init commit"
[master (root-commit) 34c4fa5] init commit
1 file changed, 10 insertions(+)
create mode 100644 example.tf
[2016-03-04T18:25:32] micperez in terraform_test [git:master]
λ terraform push -name="puhrez/getting-started"
Uploading Terraform configuration...
Configuration "puhrez/getting-started" uploaded! (v1)
```
The description field for a managed-zone is now a required field when using the Cloud API.
This commit defaults the field to use the text "Managed by Terraform" to minimize required boilerplate for Terraform users.
Ref: https://cloud.google.com/sdk/gcloud/reference/dns/managed-zones/create
The `description` field is easy to confuse for a nice field to
add an arbitrary comment to - and it's surprising that changes to this
field force a new resource, so we add a big note about it to point users
at tags.
Also marked all the other ForceNew attributes on this resource.
tls_self_signed_cert is really just a shorthand over tls_cert_request and
tls_locally_signed_cert, so rather than duplicating all of this
documentation and risking that it will get out of sync (since the
structure is shared in the implementation) we'll just link to the
existing docs.
This fixes#5343.
This commit fixes and cleans up instance block_device configuration.
Reverts #5354 in that `volume_size` is only required in certain
block_device configuration combinations. Therefore, the actual
attribute must be set to Optional and later checks done.
Doc upates, too.
This commit adds the ability to create instances with multiple
ephemeral disks. The ephemeral disks will appear as local block
devices to the instance.
The `volume_size` of a `block_device` was originally set to Optional,
but it's a required parameter in the OpenStack/Nova API. While it's
possible to infer a default size of the block device, making it required
more closely matches the Nova CLI client as well as provides consistent
experience when working with multiple block_devices.
This resource is the first which makes use of the new Riviera library
(at https://github.com/jen20/riviera), so there is some additional set
up work to add the provider to the client which gets passed among
resources.
This commit adds the ability to associate a Floating IP to a specific
network. Previously, there only existed a top-level floating IP
attribute which was automatically associated with either the first
defined network or the default network (when no network block was
used).
Now floating IPs can be associated with networks beyond the first
defined network as well as each network being able to have their own
floating IP.
Specifying the floating IP by using the top-level floating_ip
attribute and the per-network floating IP attribute is not possible.
Additionally, an `access_network` attribute has been added in order
to easily specify which network should be used for provisioning.
See the updated docs for more details and examples, but in short this
enables the `attributes` param from the Chef provisioner to accept a
raw JSON string.
Fixes#3074Fixes#3572
It was a mistake to switched fully to `==` when activating waiting for
capacity on updates in #3947. Users that didn't set `min_elb_capacity ==
desired_capacity` and instead treated it as an actual "minimum" would
see timeouts for every create, since their target numbers would never be
reached exactly.
Here, we fix that regression by restoring the minimum waiting behavior
during creates.
In order to preserve all the stated behavior, I had to split out
different criteria for create and update, criteria which are now
exhaustively unit tested.
The set of fields that affect capacity waiting behavior has become a bit
of a mess. Next major release I'd like to rework all of these into a
more consistently named block of config. For now, just getting the
behavior correct and documented.
(Also removes all the fixed names from the ASG tests as I was hitting
collision issues running them over here.)
Fixes#4792
of the database after creation. So we need to be able to
set the CharacterSetName on creation.
This is an option and will automagically default to
AL32UTF8.
The AWS SDK will give you an error message if you try to
apply this setting to other engines. The patch will only
report the character_set_name attribute, if CharacterSetName
is set on the instance.
Signed-off-by: Lars Bahner <lars.bahner@gmail.com>
This function returns -1 for negative numbers, 0 for 0 and 1 for positive numbers.
Useful when you need to set a value for the first resource and a different value for the rest of the resources.
Example: `${element(split(",", var.r53_failover_policy), signum(count.index))}`
This commit adds support for declaring variable types in Terraform
configuration. Historically, the type has been inferred from the default
value, defaulting to string if no default was supplied. This has caused
users to devise workarounds if they wanted to declare a map but provide
values from a .tfvars file (for example).
The new syntax adds the "type" key to variable blocks:
```
variable "i_am_a_string" {
type = "string"
}
variable "i_am_a_map" {
type = "map"
}
```
This commit does _not_ extend the type system to include bools, integers
or floats - the only two types available are maps and strings.
Validation is performed if a default value is provided in order to
ensure that the default value type matches the declared type.
In the case that a type is not declared, the old logic is used for
determining the type. This allows backwards compatiblity with previous
Terraform configuration.
Adds the `TF_SKIP_REMOTE_TESTS` env var to be used in cases where the
`http.Get()` smoke test passes but the network is not able to service
the needs of the tests.
Fixes#4421
This means that terraform commands like `plan`, `apply`, `show`, and
`graph` will expand all modules by default.
While modules-as-black-boxes is still very true in the conceptual design
of modules, feedback on this behavior has consistently suggested that
users would prefer to see more verbose output by default.
The `-module-depth` flag and env var are retained to allow output to be
optionally limited / summarized by these commands.
http and https SNS topic subscription endpoints require confirmation to set a valid arn otherwise
arn would be set to "pending confirmation". If the endpoints auto confirm then arn is set
asynchronously but if we try to create another subscription with same parameters then api returns
"pending subscription" as arn but does not create another a duplicate subscription. In order to
solve this we should be fetching the subscription list for the topic and identify the subscription
with same parameters i.e., protocol, topic_arn, endpoint and extract the subscription arn.
Following changes were made to support the http/https endpoints that auto confirms
1. Added 3 extra parameters i.e.,
1. endpoint_auto_confirms -> boolean indicates if end points auto confirms
2. max_fetch_retries -> number of times to fetch subscription list for the topic to get the subscription arn
3. fetch_retry_delay -> delay b/w fetch subscription list call as the confirmation is done asynchronously.
With these parameters help added support http and https protocol based endpoints that auto confirm.
2. Update website doc appropriately
In most cases private keys are used to produce certs and cert requests,
but there are some less-common cases where the PEM-formatted keypair is
used alone. The public_key_pem attribute supports such cases.
This also includes a public_key_openssh attribute, which allows this
resource to be used to generate temporary OpenSSH credentials, so that
e.g. a Terraform configuration could generate its own keypair to use
with the aws_key_pair resource. This has the same caveats as all cases
where we generate private keys in Terraform, but could be useful for
temporary/throwaway environments where the state either doesn't live for
long or is stored securely.
This builds on work started by Simarpreet Singh in #4441 .
This adds acceptance tests for specifying extra hosts on Docker
containers. It also renames the repeating block from `hosts` to `host`,
which reads more naturally in the schema when multiple instances of the
block are declared.
This allows specification of the profile for the shared credentials
provider for AWS to be specified in Terraform configuration. This is
useful if defining providers with aliases, or if you don't want to set
environment variables. Example:
$ aws configure --profile this_is_dog
... enter keys
$ cat main.tf
provider "aws" {
profile = "this_is_dog"
# Optionally also specify the path to the credentials file
shared_credentials_file = "/tmp/credentials"
}
This is equivalent to specifying AWS_PROFILE or
AWS_SHARED_CREDENTIALS_FILE in the environment.
The comment on first line of the code example is 82 characters long
and is cut on the 80-th character when viewed online. The second line
contains only two letters "on" without # in front.
The comment is displayed on two lines anyway, it is better if it is split to
two lines of less than 80 characters.
When spinning up from a snapshot or a read replica, these fields are
now optional:
* allocated_storage
* engine
* password
* username
Some validation logic is added to make these fields required when
starting a database from scratch.
The documentation is updated accordingly.
AWS does some funky stuff to handle all the variations in certificates that CA's like to hand out to users. This commit adds a note about this and details how to avoid issues. See #3837 for more information.
Only use the create_before_destroy-hook in launch configurations. The autoscaling group must not use the create_before_destroy-hook, because it can be updated (and not destroyed + re-created). Using the create_before_destroy-hook in autoscaling group also leads to unwanted cyclic dependencies.
This adds a new resource to template to generate multipart cloudinit
configurations to be used with other providers/resources.
The resource has the ability gzip and base64 encode the parts.
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).
This commit adds the openstack_lb_member_v1 resource. This resource models a
load balancing member which was previously coupled to the openstack_lb_pool_v1
resource.
By creating an actual member resource, load balancing members can now be
dynamically managed through terraform.
Added new section to end of Markdown file for OpenStack security groups,
recommending that security groups are referenced by the name attribute
instead of by the ID attribute.
- Add documentation for resources
- Rename files to match standard patterns
- Add acceptance tests for resource groups
- Add acceptance tests for vnets
- Remove ARM_CREDENTIALS file - as discussed this does not appear to be
an Azure standard, and there is scope for confusion with the
azureProfile.json file which the CLI generates. If a standard emerges
we can reconsider this.
- Validate credentials in the schema
- Remove storage testing artefacts
- Use ARM IDs as Terraform IDs
- Use autorest hooks for logging
Added acceptance test for creation in folders
Added 'baseName' as computed schema attribute for convenience
Added 'base_name' computed attribute for convenience
Added new vsphere folder resource
Fixed folder behavior
Assure test folders are properly removed
Avoid creating recreating search index in loop
Fix typeo in vsphere.createFolder
Updated website documentation
Renamed test folders to be unique across tests
Fixes based on acc test findings; code cleanup
Added combined folder and vm acc test
Restored newline; fixed skipped acc tests
Marked 'existing_path' as computed only
Removed debug logging from tests
Changed folder read to return error
Conflicts:
builtin/providers/google/provider.go
builtin/providers/google/resource_subscription.go
builtin/providers/google/resource_subscription_test.go
golang pubsub SDK has been released. moved topics/subscriptions to use that
Conflicts:
builtin/providers/google/provider.go
builtin/providers/google/resource_subscription.go
builtin/providers/google/resource_subscription_test.go
file renames and add documentation files
remove typo'd merge and type file move
add to index page as well
only need to define that once
remove topic_computed schema value
I think this was used at one point but is no longer. away.
cleanup typo
adds a couple more config values
- ackDeadlineSeconds: number of seconds to wait for an ack
- pushAttributes: attributes of a push subscription
- pushEndpoint: target for a push subscription
rearrange to better match current conventions
respond to all of the comments
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.
Building on the work of #3846, deprecate `filename` in favor of a
`template` attribute that accepts file contents instead of a path.
Required a bit of work in the interpolation code to prevent Terraform
from assuming that template interpolations were resource variables that
needed to be resolved. Leaving them as "Unknown Variables" prevents
interpolation from happening early and lets the `template_file` resource
do its thing.
This commit makes some quick updates to the port attributes to make them
more intuitive:
* `security_groups` to `security_group_ids`: since the port is expecting
IDs and not security group names like in other areas of OpenStack.
* `admin_state_up`: change to Boolean to match this same attribute on
other resources.
* `fixed_ips` to `fixed_ip`: while multiple `fixed_ip` blocks can be
specified, only one fixed IP can be specified in each block.
Builds on the work of #3846, shifting the Chef provisioner's
configuration options from `secret_key_path` and `validation_key_path`
over to `secret_key` and `validation_key`.
We've been moving away from config fields expecting file paths that
Terraform will load, instead prefering fields that expect file contents,
leaning on `file()` to do loading from a path.
This helps with consistency and also flexibility - since this makes it
easier to shift sensitive files into environment variables.
Here we add a little helper package to manage the transitional period
for these fields where we support both behaviors.
Also included is the first of several fields being shifted over - SSH
private keys in provisioner connection config.
We're moving to new field names so the behavior is more intuitive, so
instead of `key_file` it's `private_key` now.
Additional field shifts will be included in follow up PRs so they can be
reviewed and discussed individually.
* 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
...
This tripped me up today when I was trying to connect using MFA. I had a look at the source and found the token property, tested it out and low and behold it worked!
Hopefully this saves someone else going through the same pain
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.
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
Why:
* The current example for passing arguments to a local script does not
include making the uploaded file executable.
This change addresses the need by:
* Add a step to make the uploaded script executable to the example
showing how to pass arguments to an uploaded script.
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.
Here we add an OpsWorks client instance to the central client bundle and
establish a new documentation section, both of which will be fleshed out in
subsequent commits that add some OpsWorks resources.
For those accustomed to running commands via a shell it may not be clear
why this argument is a list and what the elements of that list should be.
Hopefully giving an example will help people understand what is expected.
This is in response to the misunderstanding discovered in #3011.
There isn't any precedent for abbreviating words in the interpolation
function names, and it may not be clear to all users what "enc" and "dec"
are short for, so instead we'll prefer to spell out the whole words for
improved readability.
An earlier version of the provider implementation accepted
key_material_file instead of key_material. This was updated in the
resource-specific docs but not in this provider-wide example.
The existing 404 page didn't quite fit in with the style of the rest of the site.
Fixes this by adding a layout value for use during rendering, and adds some nicer markup.
* '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.
Common metadata state is now stored
Optimistic locking support added to common_metadata
Revisions to keys in project metadata are now reflected in the project state
Wrote tests for project metadata (all pass)
Relaxed test conditions to work on projects with extra keys
Added documentation for project metadata
- Added a retry loop for attaching disks as this something was tried to
fast when the VM was still booting
- Fix issue #3033
- Update docs for latest updates and done some minor refactoring
(styling)
* 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
As reported in #2782, the math operations, specifically subtraction,
can cause unexpected behavior when resource or variable names use hyphens.
I added clarification about using spaces with math operators as well as
which operations are available.
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
...
With so many AWS provider resources, the docs are getting pretty hard
to navigate. This is particularly true due to the mismatch of some
resources encoding the service name (like aws_route53_record) but some
others ignoring it (like aws_subnet) or using a generic prefix (like
aws_db_instance), which causes an alphabetical ordering to muddle
up all of the services.
Since the AWS UI and docs are themselves oriented around services, most
users should be familiar with the service brands and understand which
resources belong to which service. Thus this categorization follows the
primary categorization used within the AWS Console, preferring EC2-VPC
over EC2-Classic-style bucketing.
Boy van Duuren