Skip to content

fix(vertexai): implement Read for EndpointWithModelGardenDeployment - #18547

Open
syangcode wants to merge 1 commit into
GoogleCloudPlatform:mainfrom
syangcode:fix/vertex-ai-mg-deployment-read-support
Open

fix(vertexai): implement Read for EndpointWithModelGardenDeployment#18547
syangcode wants to merge 1 commit into
GoogleCloudPlatform:mainfrom
syangcode:fix/vertex-ai-mg-deployment-read-support

Conversation

@syangcode

@syangcode syangcode commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

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 itself is readable at the resource's self_link, so Read just needed wiring up. The complication is that the response doesn't line up with the resource 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 up to the top-level keys the generated flatteners look for, and clears the id if the model was undeployed out of band.

Two kinds of fields are taken from state instead of from the response:

  • Write-only deploy inputs (accept_eula, hugging_face_access_token, hugging_face_cache_enabled, publisher_model_name), which the Endpoint resource never returns.
  • required_replica_count, spot, and multihost_gpu_node_count, which the API omits when they hold their zero value. Without this they show up as 0 -> null diffs on every plan.

This covers the drift-detection half of hashicorp/terraform-provider-google#27250. The in-place replica-count half shipped in #18116.

vertexai: fixed `google_vertex_ai_endpoint_with_model_garden_deployment` not detecting drift, because the resource had no Read implementation; out-of-band changes to the deployed model are now surfaced on `terraform plan`

Testing

Tested by hand against a live deployment (paligemma-224-float32 on g2-standard-12 + NVIDIA_L4, us-west1):

  1. After apply, state and the API both report min/max = 1 2.
  2. terraform plan is clean, exit 0. Worth checking separately from step 4, since a decoder that catches real drift but also introduces phantom diffs would be a net regression.
  3. Bumped maxReplicaCount to 4 out of band via endpoints:mutateDeployedModel.
  4. terraform plan exits 2 and reports ~ max_replica_count = 4 -> 2.

Step 4 exits 0 with "No changes" on released v7.42.0.

The step 4 plan is will be updated in-place, not must be replaced, so reconciling drift won't rotate the endpoint's dedicated DNS hostname.

The resource is generated with `exclude_read: true`, so the generated Read
is a no-op (`return nil`). Terraform never reconciles state with the live
Endpoint, so out-of-band changes to the deployed model are silently
ignored and `terraform plan` reports "No changes" even when the deployment
has drifted.

The Endpoint is fully readable at the resource's `self_link`, so Read only
needed wiring up. The response shape does not line up with the resource
schema though: per-deployed-model state lives inside `deployedModels[]`,
while the schema places those fields under
`deploy_config.dedicated_resources.*`, `model_config.*`, and
`endpoint_config.*`. A decoder locates the DeployedModel matching
`deployed_model_id`, lifts its fields onto the top-level keys the
generated flatteners expect, and clears the id if the model was
undeployed out of band.

Two classes of field are carried over from state rather than read:

  * Write-only deploy inputs (`accept_eula`, `hugging_face_access_token`,
    `hugging_face_cache_enabled`, `publisher_model_name`) are never echoed
    back by the Endpoint resource.
  * `required_replica_count`, `spot`, and `multihost_gpu_node_count` are
    omitted by the API when they hold their zero value, which would
    otherwise surface as spurious `0 -> null` diffs.

This completes the drift-detection half of
hashicorp/terraform-provider-google#27250; the in-place replica-count half
shipped in GoogleCloudPlatform#18116. Import support builds on this Read and will follow
separately.

```release-note:bug
vertexai: fixed `google_vertex_ai_endpoint_with_model_garden_deployment` not detecting drift, because the resource had no Read implementation; out-of-band changes to the deployed model are now surfaced on `terraform plan`
```
@modular-magician modular-magician added the awaiting-approval Pull requests that need reviewer's approval to run presubmit tests label Aug 6, 2026
@c2thorn

c2thorn commented Aug 6, 2026

Copy link
Copy Markdown
Member

Github actions was done earlier today. Starting the build now.

@modular-magician modular-magician added service/aiplatform-prediction and removed awaiting-approval Pull requests that need reviewer's approval to run presubmit tests labels Aug 6, 2026
@modular-magician

modular-magician commented Aug 6, 2026

Copy link
Copy Markdown
Collaborator

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

Diff report

Your PR generated the following diffs in downstream repositories:

Repository Diff Link Changes
google provider View Diff 1 file changed, 229 insertions(+), 2 deletions(-)
google-beta provider View Diff 1 file changed, 229 insertions(+), 2 deletions(-)

Test report

Analytics

Total Tests Passed Skipped Affected
113 99 7 7
Affected Service Packages
  • vertexai

Learn how VCR tests work


Step 1: Replaying Mode

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
  • TestAccVertexAIEndpointWithModelGardenDeployment_basic
  • TestAccVertexAIEndpointWithModelGardenDeployment_huggingfaceModel
  • TestAccVertexAIEndpointWithModelGardenDeployment_multipleModelsInSequence
  • TestAccVertexAIEndpointWithModelGardenDeployment_pscEndpoint
  • TestAccVertexAIEndpointWithModelGardenDeployment_pscEndpointAutomated
  • TestAccVertexAIEndpointWithModelGardenDeployment_withConfigs
  • TestAccVertexAIFeatureOnlineStoreFeatureview_vertexAiFeatureonlinestoreFeatureview_featureRegistry_updated

View the replaying VCR build log


Step 2: Recording Mode

Recording Mode Replaying Rerun Test Name
❌ Error · Log - TestAccVertexAIEndpointWithModelGardenDeployment_basic
❌ Error · Log - TestAccVertexAIEndpointWithModelGardenDeployment_huggingfaceModel
❌ Error · Log - TestAccVertexAIEndpointWithModelGardenDeployment_multipleModelsInSequence
❌ Error · Log - TestAccVertexAIEndpointWithModelGardenDeployment_pscEndpoint
❌ Error · Log - TestAccVertexAIEndpointWithModelGardenDeployment_pscEndpointAutomated
❌ Error · Log - TestAccVertexAIEndpointWithModelGardenDeployment_withConfigs
❌ Error · Log - TestAccVertexAIFeatureOnlineStoreFeatureview_vertexAiFeatureonlinestoreFeatureview_featureRegistry_updated

Caution

Issues requiring attention before PR completion

🔴 Initial Recording Failed: Some tests failed during the recording step. See the table above for details.

Please address these issues to complete your PR. If you believe these detections are incorrect or unrelated to your change, please raise the concern with your reviewer.

View the recording VCR build log or the debug logs folder for detailed results.

@syangcode VCR tests complete for a31310d!

@c2thorn c2thorn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

       Error: Error waiting to create EndpointWithModelGardenDeployment: Error waiting for Creating EndpointWithModelGardenDeployment: Error code 13, message: Internal error occurred. Contact Vertex AI.

Any idea @syangcode ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants