Update the resource getter method when instance is not active

[jharshika]

This pull request addresses issue hashicorp/terraform-provider-google#7810. If the activation policy is not ALWAYS i.e. the instance is not active, return from the get resource method of "user" and "database". In the API layer if the activation policy is not set the ALWAYS then get resource will throw an error. To avoid breaking terraform plan, updating the getter method to avoid the error during refresh.

With these changes, terraform plan and terraform apply will succeed. If the customer try to update/delete the resource, it will still throw exception as it is not supported for inactive resources.

Release Note Template for Downstream PRs (will be copied)

sql: google_sql_database_instance can break refresh when activation_policy is set to NEVER

[github-actions]

Hello! I am a robot. Tests will require approval from a repository maintainer to run.

@SarahFrench, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look.

You can help make sure that review is quick by doing a self-review and by running impacted tests locally.

[modular-magician]

Hi there, I'm the Modular magician. I've detected the following information about your changes:

Diff report

Your PR generated some diffs in downstreams - here they are.

google provider: Diff ( 2 files changed, 15 insertions(+), 5 deletions(-))
google-beta provider: Diff ( 2 files changed, 15 insertions(+), 5 deletions(-))

[modular-magician]

Tests analytics

Total tests: 97
Passed tests: 76
Skipped tests: 14
Affected tests: 7

Click here to see the affected service packages

• sql

Action taken

Found 7 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests

• TestAccDataSourceSqlDatabase_basic
• TestAccDataSourceSqlDatabases_basic
• TestAccSQLDatabase_sqlDatabaseBasicExample
• TestAccSQLDatabase_sqlDatabaseDeletionPolicyExample
• TestAccSqlDatabaseInstance_multipleOperations
• TestAccSqlDatabase_basic
• TestAccSqlDatabase_update

Get to know how VCR tests work

[modular-magician]

$\textcolor{green}{\textsf{Tests passed during RECORDING mode:}}$
TestAccDataSourceSqlDatabase_basic[Debug log]
TestAccDataSourceSqlDatabases_basic[Debug log]
TestAccSQLDatabase_sqlDatabaseBasicExample[Debug log]
TestAccSQLDatabase_sqlDatabaseDeletionPolicyExample[Debug log]
TestAccSqlDatabaseInstance_multipleOperations[Debug log]
TestAccSqlDatabase_basic[Debug log]
TestAccSqlDatabase_update[Debug log]

$\textcolor{green}{\textsf{No issues found for passed tests after REPLAYING rerun.}}$

---

$\textcolor{green}{\textsf{All tests passed!}}$

View the build log or the debug log for each test

[SarahFrench]

Hi @jharshika, thanks for pivoting from your previous approach to solve this issue!

I believe I understand the problem and the solution in this PR is option 5 described in the linked GitHub issue:

Option 5: Check the activation_policy before refreshing

Given the existing tests all pass here it looks like this change doesn't impact provisioning google_sql_* resources. However it looks like there are no tests covering the scenario that triggers the API errors in the linked GitHub issue.

Could you please add an acceptance test that would have triggered the API error prior to your PR? I'm imagining an update test where the first step provisions a google_sql_database_instance with activation_policy="ALWAYS", a google_sql_database, and a google_sql_user resource, and then in a second step activation_policy is updated to "NEVER"? There might be a better approach that better resembles how a user might trigger this API error, but either way I think we should add a test to prove the issue is solved.