Some AMIs have a RootDeviceName like "/dev/sda1" that does not appear as a
DeviceName in the BlockDeviceMapping list (which will instead have
something like "/dev/sda")
While this seems like it breaks an invariant of AMIs, it ends up working
on the AWS side, and AMIs like this are common enough that we need to
special case it so Terraform does the right thing.
Our heuristic is: if the RootDeviceName does not appear in the
BlockDeviceMapping, assume that the DeviceName of the first
BlockDeviceMapping entry serves as the root device.
fixes#2224
I was getting an error about a missing 'name' parameter when using the snippet from the docs that referenced a path value. Looking into the source, I found it was actually supposed to be name for the atlas provider.
* adds `bastion_*` fields to `connection` which add configuration for a
bastion host
* if `bastion_host` is set, connect to that host first, then jump
through it to make the SSH connection to `host`
* enables SSH Agent forwarding by default
* 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 changes SSH Agent utilization from opt-in to opt-out, bringing
Terraform in line with the behavior of Packer and the `ssh` command
itself.
But skip SSH agent connections if the SSH_AUTH_SOCK env var doesn't exist,
whcih means there's no agent to connect to.
Currently Terraform is leaking goroutines and with that memory. I know
strictly speaking this maybe isn’t a real concern for Terraform as it’s
mostly used as a short running command line executable.
But there are a few of us out there that are using Terraform in some
long running processes and then this starts to become a problem.
Next to that it’s of course good programming practise to clean up
resources when they're not needed anymore. So even for the standard
command line use case, this seems an improvement in resource management.
Personally I see no downsides as the primary connection to the plugin
is kept alive (the plugin is not killed) and only unused connections
that will never be used again are closed to free up any related
goroutines and memory.
This change allows the user to specify `-backend-config="encrypt=1"`
to tell S3 to encrypt the data that's in the bucket when using S3
for remote config storage.
The encryption uses "Amazon S3-managed encryption keys" so it should
not require any further user intervention.
A line was added to the unit test just for coverage.
The acceptance test was modified to:
a) Use encryption
b) Push some test data up to the bucket created to ensure
that Amazon accepts the header.
* master: (23 commits)
typo
Update CHANGELOG.md
provider/aws: Add docs for autoscaling_policy + cloudwatch_metric_alarm
provider/aws: Add autoscaling_policy
provider/aws: Add cloudwatch_metric_alarm
Update CHANGELOG.md
Update CHANGELOG.md
provider/template: don't error when rendering fails in Exists
Update CHANGELOG.md
Added Azure SQL server and service support.
Update CHANGELOG.md
docs: clarify wording around destroy/apply args
Getting Started: Added a Next Step upon finishing install.
docs: add description of archive format to download page
docs: snapshot plugin dependencies when releasing
add v0.5.3 transitory deps
Fixes support for changing just the read / write capacity of a GSI
Change sleep time for DynamoDB table waits from 3 seconds to 5 seconds
Remove request for attribute changes
Fix AWS SDK imports
...
Paul Hinze