@melinath to triage

@iperetz-goo what do you think about this?

@melinath yep thats a reasonable request, we expose this capability in the API via a request parameter - force=true
Usually users want this in cases when the validation failure are expectable to them

My current work-around is to ClickOps the resource with identical values to what's defined in HCL code, then import the resource with an import {} block. And it imports successfully with zero changes.

We are facing the same issue when creating the google_datastream_connection_profile. More specifically whe try to set up the connection to cloudsql using a private connection and a proxy service. The proxy is being created in a later stage of the pipeline (on gke) so the validation of the connection to cloudsql is not working at the moment when it is created through terraform.
Since the whole pipeline includes creating everything (including the gcp project) we have this odd race condition like the one mentioned above. Would like to see a way to ignore the validation on the connection_profile

@tcaddy Can you provide sample code on your work around.

I actually figured out the cause of my issue and it kinda explains how my "work around" even worked in the first place.

Here's what happened: we were refreshing a lower environment with a restore of the prod database. It just so happens that we had the same username and host for the cloud sql users in both production and lower environments, but the passwords were different.

Terraform never detected the drift (the fact that the passwords didn't match). The solution is to delete the cloud sql user accounts after restore and let terraform recreate them with the correct password.

@tsantandreu

Creating the profile without validation would be still useful. When a proxy is needed to connect the datastream to cloudsql, a proxy is needed. Creating this proxy is not necessarily tied to the same process. This causes terraform to fail because of the validation