* Change deprecated fields back to 'Removed'
To provide a better user experience we're going to mark the fields as removed
so that users will get a more accurate error message. We will follow up a while
later to actually remove them from schema.
Removing disk_encryption_key_sha256 and disk_encryption_key_raw and removing the custom diff logic associated with them.
<!-- This change is generated by MagicModules. -->
/cc @chrisst
This is the diff after running GoogleCloudPlatform/magic-modules#690.
We're applying it manually to fix the build, because the magician won't
pull the code to create this PR until the code can be built.
Hi!
Now any changes of cloud build trigger create new one, this PR makes triggers modifiable in place.
I referred to [bigquery dataset](9f0b792f09/google/resource_bigquery_dataset.go (L353)). If theare are better examples, I'd like to know them.
Match the bigtable_instance resource to the API structure, deprecating
the inlined config parameters. This is a complicated deprecation,
because we don't want to ForceNew when updating to use the new
undeprecated fields, but we want to ForceNew if they change.
This is achieved using a CustomizeDiff.
Refactor `google_sql_database_instance` to use Expand functions in Create. Update will start using them when we make the resource authoritative, this change does not modify the resource functionality.
Update (Regional) Instance Group Managers to deprecate the beta fields
(rolling_update_policy, versions, and auto_healing_policy). Also, rename
RESTART to REPLACE for Instance Group Manager's update_strategy, to be a
bit clearer. This required a DiffSuppress to make sure RESTART and
REPLACE are considered equivalent. In 2.0.0, we should remove RESTART
and drop the DiffSuppressFunc. Sadly, we have no way to do a deprecation
message for RESTART. We'll have to put it in the CHANGELOG. I've already
removed it from the website.
Flattening disks involves taking the relative link of each disk. This
only works if you start from a self_link, but we were starting from
anything that resolveImage returns, which includes several
not-self_links.
This PR adds a test that shows the failure, and then fixes it by
expanding the output back out to a self_link before getting the relative
link from it.
Deprecate the app_engine sub-block of google_project, and create a
google_app_engine_application resource instead. Also, add some tests for
its behaviour, as well as some documentation for it.
Note that this is largely an implementation of the ideas discussed in
#2118, except we're not using CustomizeDiff to reject deletions without
our special flag set, because CustomizeDiff apparently doesn't run on
Delete. Who knew? This leaves us rejecting the deletion at apply time,
which is less than ideal, but the only other option I see is to silently
not delete the resource, and that's... not ideal, either.
This also stops the app_engine sub-block on google_project from forcing
new when it's removed, and sets it to computed, so users can safely move
from using the sub-block to using the resource without state surgery or
deleting their entire project. This does mean it's impossible to delete
an App Engine application from a sub-block now, but seeing as that was
the same situation before, and we just papered over it by making the
project recreate itself in that situation, and people Were Not Fans of
that, I'm considering that an acceptable casualty.
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_.
We don't need quite so many `GetOk`s since the client library will ignore any fields that are set to the zero value for that type. I left a few that involved error-handling or things that had to be set before other things, but this at least should make the code a bit nicer to look at.
Tests are passing except the ones that were already failing in CI.
When reading or deleting the google_project_service resource, first
retrieve the project. If it's not found, or if it's pending deletion,
remove the service, as it's functionally disabled.
Also, add a test to confirm the behaviour.
This should resolve#1292.
I'm working on Stackdriver monitoring in another branch, which required updating `google.golang.org/genproto`, which required updating `google.golang.org/grpc`, which required updating `github.com/golang/protobuf`, and so on. This PR updates all of the Google-provided deps to their latest versions. In addition, there is:
- A change in config.go to reflect an updated type name
- Five files changed by `make fmt`
Tested with `make build`, `make test`, and `make testacc`.
I also did a bit of cleanup while I was here and noticed things that I thought could be improved in the files (wording changes, removing tests that aren't quite necessary, etc.) Take a look and make sure I didn't actually remove anything important!
So, every time this test fails we are leaving behind 10 CPUs. This is a big cause of our quota problem because we are at 70!! right now. We still need to fix the test but let's also reduce this count to 1 so we leave 1/10th of the zombie instances.
Changing from a new to legacy health check also did not work so I have no clue what the issue is here. Observing the instances, they are shown as being stuck in "Instance is being verified" state for up to days.
We had a failure in the last CI run while waiting for this resource to be created, so let's increase the timeout.
```
------- Stdout: -------
=== RUN TestAccDataSourceRegionInstanceGroup
--- FAIL: TestAccDataSourceRegionInstanceGroup (631.53s)
testing.go:518: Step 0 error: Error applying: 1 error(s) occurred:
* google_compute_region_instance_group_manager.foo: 1 error(s) occurred:
* google_compute_region_instance_group_manager.foo: timeout while waiting for state to become 'created' (last state: 'creating', timeout: 5m0s)
testing.go:579: Error destroying resource! WARNING: Dangling resources
may exist. The full state and error is shown below.
Error: Error refreshing: 1 error(s) occurred:
* google_compute_region_instance_group_manager.foo: 1 error(s) occurred:
* google_compute_region_instance_group_manager.foo: google_compute_region_instance_group_manager.foo: timeout while waiting for state to become 'created' (last state: 'creating', timeout: 5m0s)
State:
FAIL
```
The hadoop test passes for me locally but fails in CI, so this should give some extra debugging information (my user acct doesn't have permissions to read the dataproc logs from the failing test).
WIP for now because I want to make sure this method of reading the logs works.
TestAccComputeDisk_timeout is expected to fail 27.77% of the time because acctest.RandString can start with a number, making an invalid `name`. Let's fix that :)
The ID that is created for a nodepool is 3 parts in the form of
<location>/<cluster>/<nodepool>. When we use the newer 4 part import
format the ID becomes that string. Then when checking the existence of
the nodepool the name is incorrectly parsed out of the ID.
When using the 4 part import form we need to set the correct ID so that
terraform can parse the name from the ID.
Closes: #1846
* 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.
