[AKS] Clarify aks update outbound type migration error for managed VNet clusters#33330
[AKS] Clarify aks update outbound type migration error for managed VNet clusters#33330
aks update outbound type migration error for managed VNet clusters#33330Conversation
️✔️AzureCLI-FullTest
|
️✔️AzureCLI-BreakingChangeTest
|
|
aks |
Agent-Logs-Url: https://github.com/Azure/azure-cli/sessions/89434938-59be-4bd2-8316-b23911d26c91 Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
Agent-Logs-Url: https://github.com/Azure/azure-cli/sessions/89434938-59be-4bd2-8316-b23911d26c91 Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
aks update outbound type migration error for managed VNet clusters
a0x1ab
left a comment
There was a problem hiding this comment.
🤖 This review was generated by the GitHub Copilot CLI agent as part of the automated bug triage pipeline.
✅ Tests Passed — Approving PR
Test Results for PR #33330 — [AKS] Clarify aks update outbound type migration error
Test Run Summary
- Scope:
test_managed_cluster_decorator.py - Targeted tests:
test_get_outbound_type,test_update_outbound_type— 2/2 PASSED - Full suite: 268/268 PASSED (0 failures, 0 regressions)
Code Review
The fix correctly addresses the root cause:
- Before: Users get
--vnet-subnet-id must be specified, butaz aks updatedoesn't accept--vnet-subnet-id→ impossible to satisfy - After: Clear message: "Updating outbound type to userDefinedRouting is only supported for clusters created with
--vnet-subnet-id" → actionable guidance
The change is scoped to update mode only; create-mode validation is unchanged. The unit test covers both the new error text and the update-mode path.
🟢 Approved — all tests pass, fix is correct.
a0x1ab
left a comment
There was a problem hiding this comment.
🤖 Copilot Squad — Reviewer (Code Analysis)
Code review result:
Changes reviewed
| File | Assessment |
|---|---|
managed_cluster_decorator.py |
✅ Logic is correct — converts static method to instance method to access self.decorator_mode, adds early InvalidArgumentValueError for UPDATE mode on managed VNet clusters |
test_managed_cluster_decorator.py |
✅ Unit test covers the new error path |
Automated VM testing: ❌ Blocked
The Tester phase could not run because Azure credentials (AZURE_CLIENT_ID / AZURE_CLIENT_SECRET) are not configured in the agent environment. Live testing on an ephemeral VM was skipped.
What a human reviewer should verify
- Run
azdev test acs(unit tests) — should pass with the new test case - Manually test
az aks update --outbound-type userDefinedRoutingon a cluster with an AKS-managed VNet to confirm the improved error message appears - Verify that
az aks update --outbound-type userDefinedRoutingwith--vnet-subnet-idstill works correctly (no regression)
Max iterations reached
Automated pipeline is escalating to human review after being unable to complete VM-based testing.
🤖 This comment was posted by the Copilot Squad AI agent — automated triage & fix pipeline.
a0x1ab
left a comment
There was a problem hiding this comment.
🤖 AI Agent | This comment was posted automatically by the GitHub Copilot agent assist loop.
✅ Reviewer — PR #33330 Approved
Issue: #33204 — Cannot use az aks update --outbound-type userDefinedRouting
Code Review Results
Code change: _raise_missing_vnet_subnet_for_outbound_type changed from @staticmethod to instance method so it can inspect self.decorator_mode.
- ✅ Single caller at line 2491 uses
self._raise_missing_vnet_subnet_for_outbound_type(...)— no breaking change from static→instance conversion - ✅ UPDATE mode now raises
InvalidArgumentValueErrorwith a clear, actionable message pointing to the docs - ✅ CREATE mode behavior is unchanged
- ✅ Unit test added covering the UPDATE path
- ✅ All 48 CI checks pass (Full Test Python 3.12 & 3.13, Style, Unit Tests, Build, Breaking Change)
Note: Azure VM-based testing was blocked (no credentials in agent environment), but the full CI suite ran and passed all tests including the new unit test.
This fix correctly addresses the root cause: az aks update does not accept --vnet-subnet-id, so suggesting it in an error message was misleading. The new message clearly explains that outbound type migration is unsupported for managed-VNet clusters and links to the relevant docs.
a0x1ab
left a comment
There was a problem hiding this comment.
🤖 AI Agent | Automated Quality Gate
✅ Test Results — Issue #33204 / PR #33330
Test environment: Local unit test run on PR branch copilot/fix-aks-update-outbound-type
| Test Suite | Result |
|---|---|
test_managed_cluster_decorator.py |
✅ 268/268 passed |
test_get_outbound_type (new assertion) |
✅ PASSED |
Validation: The new _raise_missing_vnet_subnet_for_outbound_type update-mode path raises InvalidArgumentValueError with the expected message (only supported for clusters created with --vnet-subnet-id) instead of the misleading --vnet-subnet-id must be specified... error.
No regressions detected. The fix correctly addresses the confusion described in issue #33204 by giving a clear, actionable error for managed-VNet clusters.
⚠️ Note: Azure VM provisioning was unavailable in this environment; live E2E tests against a real AKS cluster could not be run. Unit test coverage of the changed code path is complete.
Related command
az aks update --outbound-type userDefinedRoutingDescription
az aks update --outbound-type userDefinedRoutingcould fail with a message requiring--vnet-subnet-id, butaks updatedoes not accept that argument. This change makes update-time validation reflect supported migration paths for existing clusters.What changed
AKSManagedClusterContext._raise_missing_vnet_subnet_for_outbound_type, update mode now raisesInvalidArgumentValueErrorwith a migration-path message instead of a missing-argument message.User-visible effect
Targeted coverage
test_get_outbound_typeto verify update mode returns the new error text (only supported for clusters created with --vnet-subnet-id).Example
Testing Guide
History Notes
[AKS]
az aks update: Improve outbound-type update error messaging for managed VNet clusters to align with supported migration paths.This checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.
I adhere to the Error Handling Guidelines.