feat: Serverless VPC Access Connector update fields without recreating the resource

[ramonvermeulen]

Solves hashicorp/terraform-provider-google#20814

Added functionality so that updates on the fields [min_instances, max_instances, machine_type] for the google_vpc_access_connector resource will not cause recreation, and use the underlaying projects.locations.connectors/patch endpoint instead to update in-place.

Release Note Template for Downstream PRs (will be copied)

See Write release notes for guidance.

vpcaccess: changes to fields `min_instances`, `max_instances`, `machine_type` updates resource `google_vpc_access_connector` in-place without recreation.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

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

@rileykarson, 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.

[ramonvermeulen]

Unrelated question to the PR:

Is there a good way to find out which fields are mutable/immutable on the GCP API Endpoints? As far I can see this is not something that the endpoint documentation provides (or I am blind). I had to find out via a combination of checking the GCP Console UI, but then I realized that maybe some fields could be supported via API only. Then I saw this message when running the tests the first time:

Error: Error updating Connector "projects/XXXXX/locations/us-central1/connectors/tf-test-mqice1t7dx": googleapi: Error 400: Update mask contains illegal fields. Allowed fields are: [min_instances, max_instances, machine_type]

And then I figured these were the fields, probably there is a simpler way.

[rileykarson]

I haven't found one! Those match the steps I'd take personally.

[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 ( 3 files changed, 197 insertions(+), 25 deletions(-))
google-beta provider: Diff ( 3 files changed, 197 insertions(+), 25 deletions(-))

[modular-magician]

Tests analytics

Total tests: 7
Passed tests: 3
Skipped tests: 1
Affected tests: 3

Click here to see the affected service packages

• vpcaccess

Action taken

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

• TestAccVPCAccessConnectorDatasource_basic
• TestAccVPCAccessConnectorDatasource_update
• TestAccVPCAccessConnector_vpcAccessConnectorThroughput_usingThroughputOrInstancesLimits

Get to know how VCR tests work

[modular-magician]

🟢 Tests passed during RECORDING mode:
TestAccVPCAccessConnectorDatasource_update [Debug log]

🟢 No issues found for passed tests after REPLAYING rerun.

---

🔴 Tests failed during RECORDING mode:
TestAccVPCAccessConnectorDatasource_basic [Error message] [Debug log]
TestAccVPCAccessConnector_vpcAccessConnectorThroughput_usingThroughputOrInstancesLimits [Error message] [Debug log]

🔴 Errors occurred during RECORDING mode. Please fix them to complete your PR.

View the build log or the debug log for each test

[rileykarson]

Comments inline. Re: failed tests:

TestAccVPCAccessConnectorDatasource_basic - Error: Error waiting to create Connector: Error waiting for Creating Connector: Error code 3, message: Operation failed: Invalid IP CIDR range was provided. It conflicts with an existing subnetwork. Please delete the connector manually. so we'll need to pick a diff. CIDR.

TestAccVPCAccessConnector_vpcAccessConnectorThroughput_usingThroughputOrInstancesLimits was doing a recreation internally before this change and attempts to update now- that's a bit of a weird test and should be split up, but this change does interact unusually with the min_/max_ instance and throughput fields and can create invalid updates. Let me see if I can think of a good mitigation.

[ramonvermeulen]

Comments inline. Re: failed tests:

TestAccVPCAccessConnectorDatasource_basic - Error: Error waiting to create Connector: Error waiting for Creating Connector: Error code 3, message: Operation failed: Invalid IP CIDR range was provided. It conflicts with an existing subnetwork. Please delete the connector manually. so we'll need to pick a diff. CIDR.

TestAccVPCAccessConnector_vpcAccessConnectorThroughput_usingThroughputOrInstancesLimits was doing a recreation internally before this change and attempts to update now- that's a bit of a weird test and should be split up, but this change does interact unusually with the min_/max_ instance and throughput fields and can create invalid updates. Let me see if I can think of a good mitigation.

Thanks for your review! @rileykarson

Just reverted the datasource changes, I see the original test was already using 10.8.0.32/28 so let's see if this causes a problem again for TestAccVPCAccessConnectorDatasource_basic, otherwise I will change it to another CIDR block.

In resource_vpc_access_connector_test.go I implemented two tests, one expecting an in-place update when changing all the mutable fields. Another one triggering a replacement when changing an immutable field.