* Adding resource_attached_disk
This is a resource which will allow joining a arbitrary compute disk
to a compute instance. This will enable dynamic numbers of disks to
be associated by using counts.
* undelete-update recently soft-deleted custom roles
* remove my TODO statements
* check values on soft-delete-recreate for custom role tests
* final fixes to make sure delete works; return read() when updating to 'create'
* check for non-404 errors for custom role get
* add warnings to custom roles docs
Fixes#1494.
* Add import support for `google_logging_organization_sink`, `google_logging_folder_sink`, `google_logging_billing_account_sink`.
Using `StateFunc` over `DiffSuppressFunc` should only affect tests; for some reason `TestAccLoggingFolderSink_folderAcceptsFullFolderPath` expected a `folder` value of `folders/{{id}}` vs expecting `{{id}}` when only `DiffSuppressFunc` was used, when in real use `DiffSuppressFunc` should be sufficient.
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.
