As with several other sensitive values in Opsworks, the API returns a
placeholder value rather than a nil. To avoid writing the placeholder
value into the state we just skip updating the password on read, letting
whatever value was in the state persist.
This means that Terraform can't detect configuration drift where someone
has changed the password via some other means, but Terraform will still
be able to recognize changes to the password made within Terraform itself
due to the "last-written" value in the state.
This fixes#6192.
Change the `RetryFunc` from a plain `error` return type to a
specialized `RetryError` which must decide whether it is
retryable or not.
Add `RetryableError` / `NonRetryableError` factory functions that
callers are meant to use to build up these errors.
This makes it eminently clear whether or not a given error is
retryable from inside the client code.
Goal here is to _not_ change any behavior, simply reflect the
existing behavior with the new, clearer, API.
Fixes#3635
This follows the suggestion of @apparentlymart in
https://github.com/hashicorp/terraform/issues/3635#issuecomment-151000068
to fix the issue of OpsWorks stacks always complaining about the custom
cookbooks SSH key needing to be changed.
Functional tests:
* Created a new stack and gave it an SSH key. The key was written to
OpsWorks properly.
* Ran "plan" again and terraform indicated it needed to change the SSH
key, which is expected since terraform cannot read what the existing
SSH is.
* Removed the key from my resource and this time, "plan" did not have
any changes. The `tfstate` file indicated the SSH key was "" (empty
string).
* Changed an unrelated property of the stack. Previously this was not
working for me due to terraform attempting to change the SSH key.
"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.
Clint