To reduce the risk of secret exposure via Terraform state and log output,
we default to creating a relatively-short-lived token (20 minutes) such
that Vault can, where possible, automatically revoke any retrieved
secrets shortly after Terraform has finished running.
This has some implications for usage of this provider that will be spelled
out in more detail in the docs that will be added in a later commit, but
the most significant implication is that a plan created by "terraform plan"
that includes secrets leased from Vault must be *applied* before the
lease period expires to ensure that the issued secrets remain valid.
No resources yet. They will follow in subsequent commits.
To avoid the issue #8011 I have updated the used client library, with
this update I don't get the mentioned issues like `unexpected EOF`
anymore.
Fixes#8011
Fixes#5826
The `prevent_destroy` lifecycle configuration was not being checked when
the count was decreased for a resource with a count. It was only
checking when attributes changed on pre-existing resources.
This fixes that.
Fixes#5409
I didn't expect this to be such a rabbit hole!
Based on git history, it appears that for "historical reasons"(tm),
setting up the various `state.State` structures for a plan were
_completely different logic_ than a normal `terraform apply`. This meant
that it was skipping things like disabling backups with `-backup="-"`.
This PR unifies loading from a plan to the normal state setup mechanism.
A few tests that were failing prior to this PR were added, no existing
tests were changed.
* Pass over the Interpolation page
Fixes some grammar, typos and structure. Updated some headings and fixed
a couple of spelling mistakes.
* Added proper note syntax
* Turned some notes into actual notes
* Couple of minor typos just noticed
Fixes#5138
If an item is optional and is removed completely from the configuration,
it should still trigger a destroy/create if the field itself was marked
as "ForceNew".
See the example in #5138.
Fixes#5338 (and I'm sure many others)
There is no use case for "simple" variables in Terraform at all so
anytime one is found it should be an error.
There is a _huge_ backwards incompatibility here that was not supposed
to be by design but I'm sure a lot of people are relying on: in the
`template_file` datasource, this bug allowed you to not escape your
interpolations and have the work. For example:
```
data "template_file" "foo" {
template = "${a}"
vars { a = 12 }
}
```
The above would work, but it shouldn't. The template should have to be
`"$${a}"` (to escape the interpolation).
Because of this BC, I recommend holding this until Terraform 0.8.0 and
documenting it carefully. As part of this PR, I've added some special
error message notes.
* provider/google Document MySQL versions for second generation instances
Google Cloud SQL has first-gen and second-gen instances with different
supported versions of MySQL.
* provider/google Increase SQL Admin operation timeout to 10 minutes
Creating SQL instances for MySQL 5.7 can take over 7 minutes,
so the timeout needs to be increased to allow the
google_sql_database_instance resource to successfully create.
The underlying [go-getter](https://github.com/hashicorp/go-getter)
supports S3 Buckets and unarchiving. Adding mentions of this to the
module sources documentation.
This commit adds an ability to modify the `AutoMinorVersionUpgrade` property of the
Replication Group (which is enabled by default) accordingly.
Signed-off-by: Krzysztof Wilczynski <krzysztof.wilczynski@linux.com>
Martin Atkins