fix(vertexai): pass a project ID to project_allowlist in the PSC tests - #18670
Open
syangcode wants to merge 1 commit into
Open
fix(vertexai): pass a project ID to project_allowlist in the PSC tests#18670syangcode wants to merge 1 commit into
syangcode wants to merge 1 commit into
Conversation
`project_allowlist` takes a bare project ID. The two PSC tests and the published psc_endpoint_automated sample pass `data.google_project.project.id`, which renders as `projects/<project-id>`. That used to be accepted -- the committed cassettes, recorded 2026-05-14, show a successful deploy sending `projects/<project-id>` -- but EndpointService.CreateEndpoint has since tightened validation and now rejects it. The deploy pipeline reports the rejection to callers as a bare `code 13 INTERNAL` with no detail, so nothing about the offending field reaches the user; the underlying error is an INVALID_ARGUMENT naming `private_service_connect_config.project_allowlist`. Anyone who copied the sample hits the same dead end. Because these tests only run against the real API when their cassettes are invalidated, the change in API behaviour went unnoticed until a pending change to this resource forced re-recording. _pscEndpointAutomated additionally managed its own network, which cannot be torn down reliably: PSC service automation attaches firewall rules to that network and removes them asynchronously when the deployment is deleted, so the network delete races them. It now uses the shared bootstrapped network, which also drops the hardcoded network and subnetwork names that let a failed run poison the next one. Both tests pass against a real project in us-central1.
syangcode
added a commit
to syangcode/magic-modules
that referenced
this pull request
Aug 17, 2026
Two fields under endpoint_config made every plan after apply propose a destroy-and-recreate for anyone who sets that block. Neither was reachable before: the only tests that set endpoint_config are the PSC ones, and those were failing at create, so Read was never exercised with it populated. - endpoint_display_name is generated by the service and immutable. Read wrote it into state, the config never sets it, so the next plan proposed removing it and forced replacement. It and dedicated_endpoint_enabled are now default_from_api. - psc_automation_configs is a deploy-time input the Endpoint resource does not echo back; the GET returns only enablePrivateServiceConnect and projectAllowlist. Read dropped it and, being immutable, it planned as an addition that also forced replacement. The decoder now carries it over from state alongside the other write-only inputs. Verified against a real project in us-central1 with the PSC test fix from GoogleCloudPlatform#18670 applied: pscEndpoint, pscEndpointAutomated and basic all pass with an empty plan after apply.
syangcode
added a commit
to syangcode/magic-modules
that referenced
this pull request
Aug 17, 2026
The resource is generated with exclude_read: true, so the generated Read is a no-op (return nil). State is never reconciled against the live Endpoint, so out-of-band changes to the deployed model go unnoticed and terraform plan reports "No changes" even when the deployment has drifted. The Endpoint is readable at the resource's self_link, so Read just needed wiring up. The complication is that the response does not line up with the schema: per-deployed-model state lives in deployedModels[], while the schema puts those fields under deploy_config.dedicated_resources.*, model_config.* and endpoint_config.*. The decoder finds the DeployedModel matching deployed_model_id, lifts its fields to the top-level keys the generated flatteners expect, and clears the id if the model was undeployed out of band. Fields the API does not echo back are carried over from state or marked default_from_api, so Read surfaces real drift without introducing phantom diffs. Two of these would otherwise force a destroy-and-recreate on every plan for anyone who sets endpoint_config: - endpoint_display_name is generated by the service and immutable. Read wrote it into state, the config never sets it, so the next plan proposed removing it. It and dedicated_endpoint_enabled are default_from_api. - psc_automation_configs is a deploy-time input the Endpoint does not return; the GET yields only enablePrivateServiceConnect and projectAllowlist. Read dropped it and, being immutable, it planned as an addition. This covers the drift-detection half of hashicorp/terraform-provider-google#27250. The in-place replica-count half shipped in GoogleCloudPlatform#18116. Verified against a real project in us-central1 with the PSC test fix from GoogleCloudPlatform#18670 applied: pscEndpoint, pscEndpointAutomated and basic all pass with an empty plan after apply.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
project_allowlisttakes a bare project ID. The two PSC acceptance tests and the publishedpsc_endpoint_automatedsample passdata.google_project.project.id, which renders asprojects/<project-id>.That used to work. The committed cassettes, recorded 2026-05-14, show a successful deploy sending
projects/<project-id>, soEndpointService.CreateEndpointaccepted the resource-path form at the time and has since tightened validation. The underlying rejection is anINVALID_ARGUMENTnamingprivate_service_connect_config.project_allowlist, but the deploy pipeline reports it to callers as a barecode 13 INTERNALwith an empty detail, so nothing about the offending field reaches the user. Anyone who copied the sample hits the same dead end.These tests only reach the real API when their cassettes are invalidated, which is why the change in API behaviour went unnoticed for months — the last recording was in May.
_pscEndpointAutomatedalso managed its own network. PSC service automation attaches firewall rules to that network and removes them asynchronously when the deployment is deleted, so Terraform's network delete races them and destroy fails. It now uses the shared bootstrapped network, which also drops the hardcodednetworkandsubnetworknames that let a failed run poison the next one.Testing
Both tests pass against a real project in us-central1, with an empty plan after apply:
TestAccVertexAIEndpointWithModelGardenDeployment_pscEndpoint— 585sTestAccVertexAIEndpointWithModelGardenDeployment_pscEndpointAutomated— 1386sBefore this change both failed at create in every environment tried: four CI runs, plus us-west1 and us-central1 locally.
Split out of #18547 so it can land on its own — the breakage is an API behaviour change rather than part of the Read work in that PR, and #18547's PSC tests cannot go green until this merges.