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.
Paul Hinze