Upgrade agent sandbox v0.5.3

[safiya2610]

Description

This PR upgrades the sigs.k8s.io/agent-sandbox dependency from v0.4.6 to the latest stable release v0.5.3.

As part of this upgrade, all internal workload manager logic and tests have been migrated to use the newly introduced agents.x-k8s.io/v1beta1 and extensions.agents.x-k8s.io/v1beta1 APIs, replacing the older v1alpha1 types.

Key Changes

• Dependency Update: Bumped sigs.k8s.io/agent-sandbox to v0.5.3 in go.mod and go.sum.
• v1beta1 Migration:
  • Updated all Sandbox, SandboxClaim, SandboxWarmPool, and SandboxTemplate usages in pkg/workloadmanager to v1beta1.
  • Updated SandboxClaim construction to use WarmPoolRef instead of the deprecated TemplateRef.
• Immutability Contract: Added TestSandboxVolumeClaimTemplatesImmutability to explicitly enforce and test the new immutability behavior of Sandbox.spec.volumeClaimTemplates.
• Unit & E2E Tests: Migrated test/e2e/e2e_test.go and all internal pkg/workloadmanager tests to construct and validate v1beta1 objects. Fixed namespace validation defaulting logic in the HTTP creation handler.
• E2E Scripts: Configured run_e2e.sh to fetch the v0.5.3 sandbox-with-extensions.yaml manifest.

Fixes #438

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[volcano-sh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign hzxuzhonghu for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 66.33663% with 34 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.87%. Comparing base (3b19390) to head (8a528f1).
⚠️ Report is 36 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/workloadmanager/codeinterpreter_controller.go	40.62%	19 Missing ⚠️
pkg/workloadmanager/k8s_client.go	26.66%	11 Missing ⚠️
pkg/workloadmanager/handlers.go	86.95%	3 Missing ⚠️
pkg/workloadmanager/sandbox_controller.go	0.00%	1 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #446      +/-   ##
==========================================
+ Coverage   58.41%   59.87%   +1.45%     
==========================================
  Files          36       36              
  Lines        3463     3621     +158     
==========================================
+ Hits         2023     2168     +145     
- Misses       1231     1234       +3     
- Partials      209      219      +10     

Flag	Coverage Δ
unittests	59.87% <66.33%> (+1.45%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ranxi2001]

#448 has merged into main. Please rebase this PR onto the latest main and drop the overlapping SSE workaround from 83002f1; the merged SDK v2 migration keeps the MCP integration on Streamable HTTP and should resolve the current overlap.

/retest

[volcano-sh-bot]

@ranxi2001: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

Details

In response to this:

#448 has merged into main. Please rebase this PR onto the latest main and drop the overlapping SSE workaround from 83002f1; the merged SDK v2 migration keeps the MCP integration on Streamable HTTP and should resolve the current overlap.

/retest

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[safiya2610]

#448 has merged into main. Please rebase this PR onto the latest main and drop the overlapping SSE workaround from 83002f1; the merged SDK v2 migration keeps the MCP integration on Streamable HTTP and should resolve the current overlap.

/retest

doing it..

[ranxi2001]

Reviewed exact head a0f4882. The Kubernetes/code-generator version skew is fixed and the current checks pass. I found one authorization regression and three current-head compatibility/operational gaps in the inline comments.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[ranxi2001]

Thanks for the updates. I verified the migrated-claim Ready wait, Store owner propagation, and codegen tool-path fixes on 353f1df. I left one remaining upgrade-path comment below.

[ranxi2001]

[P2] Stop before migration when webhook readiness times out

After the 30th failed probe, this branch prints diagnostics but does not exit. The loop ends and /tmp/migrate.sh --phase=migrate still runs, so the mutating storage migration can start even though the conversion webhook never became reachable.

Could you exit non-zero after the timeout diagnostics so migration only starts after a successful readiness probe?

[safiya2610]

ok, doing..

[safiya2610]

done.

[ranxi2001]

Re-reviewed exact head d7333cc. The webhook timeout path is now fail-closed, so that thread is fixed. I am not adding duplicate inline threads, but three previously raised PR-scope items still remain in the current tree:

• The migrated upgrade-bound-claim is checked for Ready and identity preservation, but the test still never deletes that same claim, verifies the captured Sandbox/Pod UIDs are garbage-collected, or proves the same pool refills. The later warm-pool test creates a fresh v1beta1 lineage, so it does not close #438's migrated-object lifecycle requirement. Existing lifecycle thread.
• The dependency bump still makes an existing AgentRuntime workloadRef unrepresentable in the embedded typed PodSpec; the current test only constructs a fresh v0.36 PodSpec and checks an image. The root guide notes the transition, but the mirrored guide and an old-object compatibility test are missing, and no maintainer has accepted dropping this stored scheduling intent. Existing compatibility thread.
• Both mandatory migration guides still wait for the conversion webhook with an unbounded until loop. A permanent failure hangs forever without diagnostics or a non-zero exit. Existing docs thread.

No new current-head P1/P2 findings beyond these. I would hold /lgtm until they are addressed or explicitly accepted by a maintainer.

[volcano-sh-bot]

Adding label do-not-merge/contains-merge-commits because PR contains merge commits, which are not allowed in this repository.
Use git rebase to reapply your commits on top of the target branch. Detailed instructions for doing so can be found here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ranxi2001]

Re-reviewed exact head 86e45ab. The bounded webhook probes in both guides now close that item. The new E2E block also runs in both current jobs, but two compatibility gaps remain:

• [P1] The refill assertion crosses object lineages. The job log shows bootstrap classifies upgrade-bound-claim as warm-started and says no shadow needed, then creates shadow-pool-e2e-upgrade-template for the separate cold claim with desired replicas 0. Deleting the standalone bound claim and scaling that unrelated pool from 0 to 1 proves initial fill, not refill of the migrated claim's source pool. The GC loop also treats any kubectl get error as deletion and never verifies the captured Pod UID or a replacement Sandbox UID. Please seed a real v0.4.6 warm pool, adopt from it, then delete the same migrated claim and require the original Sandbox/Pod UIDs to disappear and that same pool to return to desired capacity with a different Sandbox UID.

• [P2] The old-object test does not model a valid old object or verify its scheduling contract. The previous CRD required both workloadRef.name and workloadRef.podGroup, but the fixture supplies only name; the assertions then prove only that an unrelated container image survives while workloadRef is silently dropped. Because workloadRef (name, podGroup, podGroupReplicaKey) is not shape-equivalent to schedulingGroup (podGroupName), "transition those fields" does not define the migration. If dropping this alpha field is intentional, please use a schema-valid legacy payload and explicitly test and document which scheduling semantics are unsupported; otherwise map the supported intent.

I would still hold /lgtm until these two gaps are closed or explicitly accepted by a maintainer.

[ranxi2001]

Re-reviewed exact head 8a528f1. The schema-valid legacy workloadRef fixture and the explicit unsupported compatibility boundary now close that item. One lifecycle gap remains:

• [P1] The refill check still observes a different object lineage. e2e-upgrade-warmpool owns its own ready Sandbox, while upgrade-bound-sandbox is created separately and manually attached to upgrade-bound-claim without that pool's ownership or labels. The v0.5.3 conversion therefore derives warmPoolRef.name=upgrade-bound from the bound Sandbox name, not e2e-upgrade-warmpool. After deleting the claim, readyReplicas can already be 1 and the generic warm-pool label query can return the pool's pre-existing member, whose UID necessarily differs from the unrelated bound Sandbox UID. The test can therefore pass without the deletion causing a refill. Please let the v0.4.6 pool create and hand out the actual member, capture that pool/Sandbox/Pod lineage, then delete the same migrated claim and require the original UIDs to disappear and the same pool to produce a replacement Sandbox UID.