Fix Dana's comments, one of which exposed a bug: we weren't actually
fixing the diff. Because resolveImage can return multiple formats, and
only returns a self_link if a self_link is passed in, it was diffing
more often than not against a self_link supplied in the config. We just
had a bug in our CustomizeDiff function that concealed this.
I added the resolvedImageSelfLink helper function to turn the output
from resolveImage into a self_link, which fixes the problem. It also has
the knock-on effect of fixing #2067 at the same time, which is nice. I
decided to add another function instead of just modifying resolveImage
to always return a self_link because I don't want to deal with the
backwards compatibility problems of changing how we're storing a bunch
of things in state this close to 1.19.0. And honestly, we should
probably just be storing the self_link always, _anyways_.
When using instance templates, if you use one of our image shorthands at
the moment, you'll get a perma-diff. This is because the config gets
resolved to another format before it is set in state, and so we need to
set that other format in state.
Unfortunately, resolving images requires network access, so we have to
do this with CustomizeDiff. CustomizeDiff was having trouble (I think?
More on this below) on setting a field as not ForceNew once the field
was already set, so I moved the decision for whether a field was
ForceNew or not into CustomizeDiff. I also resolved the old and new
images, and if they were the same, cleared the diff.
Unfortunately, you can't actually clear a field on a sub-block right
now. You have to clear top-level fields only. So this will currently
throw an error. I opened hashicorp/terraform#18795 to fix that. Once
that's merged, and we vendor it here, this patch fixes the problem.
If hashicorp/terraform#18795 doesn't get merged, the next best
workaround is to keep track of _all_ the fields under `disk` with a diff
in our CustomizeDiff, check whether they've all changed or not, and if
they've all changed, clear the changes on `disk`, which I _think_ will
resolve the issue. That's just a massive pain, unfortunately.
This doesn't appear to be used anywhere within this project.
Additionally Hashicorp has their own [uuid library](https://github.com/hashicorp/go-uuid)
which is used internally.
@michaelharo suggested this would be a good best practice for this particular resource to prevent users from accidentally deleting a bunch of encryption keys on a -/+ and losing data, and I agree.
This commit adds a quick documentation blurb saying what actually happens if those crypto key versions are destroyed and also updates the snippet to showcase a lifecycle hook.
* fix service account key data source name
* switch id to name
* update docs
* doc format
* fixes for validation and tests
* last fixes for service account key data source
Many of the d.Set calls do not handle the error that comes back. This can lead
to things that appear to be set but are silently failing. This change adds a
flag to the makefile to force a panic if there are unhandled errors.
I largely stole these from github.com/terraform-providers/terraform-provider-aws, but with a few changes:
* I called out how we assign users to issues, to make it more transparent to users.
* I added a "success story" issue that will be automatically closed and labeled, to keep track of those stories.
* I added a `[issue-type:TYPE]` string to each, so hashibot can detect and act on them.
`govendor fetch github.com/hashicorp/terraform/...@v0.11.8`
I figured this was a good time to do it since we just had a release. I verified that everything still compiles and that a few tests are passing- I don't expect anything else to change, but if there are any weird failures that this exposes we'll catch them in CI with plenty of time before the next release.
