Our DNS tests were using terraform.test as a DNS name, which GCP was
erroring on, as we haven't proven we own the domain (and can't, as we
don't). To solve this, I updated the tests to use hashicorptest.com,
which we _do_ own, and which we have proven ownership of. The tests now
pass.
This changes removes read of the deprecated `policy_data` attr in
the `google_project` resource.
0.8.5 introduced new behavior that incorrectly read the `policy_data`
field during the read lifecycle event. This caused Terraform to
assume it owned not just policy defined in the data source, but
everything that was associated with the project. Migrating from 0.8.4
to 0.8.5, this would cause the config (partial) to be compared to the
state (complete, as it was read from the API) and assume some
policies had been explicitly deleted. Terraform would then delete them.
Fixes#11556
Cloud SQL Gen 2 instances come with a default 'root'@'%' user on
creation. This change automatically deletes that user after creation. A
Terraform user must use the google_sql_user to create a user with
appropriate host and password.
Add support for creating, updating, and deleting projects, as well as
their enabled services and their IAM policies.
Various concessions were made for backwards compatibility, and will be
removed in 0.9 or 0.10.
* removes region param from backend_service
- this param was not being used in this service
- you need a regional_backend_service if you want to pass this
* deprecated region instead of outright removing
* put session affinity formatting back
* providers/google: add support for encrypting a disk
* providers/google: Add docs for encrypting disks
* providers/google: CSEK small fixes: sensitive params and mismatched state files
* Add subnetwork_project field to allow for XPN in GCE instance templates
* Missing os import
* Removing unneeded check
* fix formatting
* Add subnetwork_project to read
As brought up in #10174, our update_strategy property for instance group
managers in GCP would always be set to "RESTART" on read, even if the
user asked for them to be "NONE" in the config.
This adds a test to ensure that the user wishes were respected, which
fails until we check for update_strategy in the ResourceData before we
update it within the Read function. Because the update_strategy property
doesn't map to anything in the API, we never need to read it from
anywhere but the config, which means the ResourceData should be
considered authoritative by the time we get to the Read function.
The fix for this was provided by @JDiPierro in #10198 originally, but
was missing tests, so it got squashed into this.
A new create_timeout attribute was added that had some backwards
incompatibilities, and as per discussion in #10823, it was determined we
could make upgrading to 0.8.x easier by fixing them, without really
losing any functionality.
Because create_timeout is not something stored or transmitted to the
API, it's not something we need a ForceNew on. Also, because an update
wouldn't result in an API call, we can add a state migration to avoid a
false positive diff that requires people to plan and apply but doesn't
actually make an API call.
Update our instance template to include metadata_startup_script, to
match our instance resource. Also, we've resolved the diff errors around
metadata.startup-script, and people want to use that to create startup
scripts that don't force a restart when they're changed, so let's stop
disallowing it.
Also, we had a bunch of calls to `schema.ResourceData.Set` that ignored
the errors, so I added error handling for those calls. It's mostly
bundled with this code because I couldn't be sure whether it was the
root of bugs or not, so I took care of it while addressing the startup
script issue.
Dana Hoffman