fix(vertexai): implement Read for EndpointWithModelGardenDeployment - #18547
fix(vertexai): implement Read for EndpointWithModelGardenDeployment#18547syangcode wants to merge 1 commit into
Conversation
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`
```
|
Github actions was done earlier today. Starting the build now. |
|
Hi there, I'm the Modular magician. I've detected the following information about your changes for commit a31310d: Diff reportYour PR generated the following diffs in downstream repositories:
Test reportAnalytics
Affected Service Packages
Step 1: Replaying Mode Action takenFound 7 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
View the replaying VCR build log Step 2: Recording Mode
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
left a comment
There was a problem hiding this comment.
Error: Error waiting to create EndpointWithModelGardenDeployment: Error waiting for Creating EndpointWithModelGardenDeployment: Error code 13, message: Internal error occurred. Contact Vertex AI.
Any idea @syangcode ?
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 andterraform planreports "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 indeployedModels[], while the schema puts those fields underdeploy_config.dedicated_resources.*,model_config.*, andendpoint_config.*. The decoder finds the DeployedModel matchingdeployed_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:
accept_eula,hugging_face_access_token,hugging_face_cache_enabled,publisher_model_name), which the Endpoint resource never returns.required_replica_count,spot, andmultihost_gpu_node_count, which the API omits when they hold their zero value. Without this they show up as0 -> nulldiffs on every plan.This covers the drift-detection half of hashicorp/terraform-provider-google#27250. The in-place replica-count half shipped in #18116.
Testing
Tested by hand against a live deployment (paligemma-224-float32 on
g2-standard-12+NVIDIA_L4, us-west1):min/max = 1 2.terraform planis 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.maxReplicaCountto 4 out of band viaendpoints:mutateDeployedModel.terraform planexits 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, notmust be replaced, so reconciling drift won't rotate the endpoint's dedicated DNS hostname.