aks-preview: Fix managedNATGatewayV2 outbound type being overwritten to loadBalancer#9748
Conversation
️✔️Azure CLI Extensions Breaking Change Test
|
|
Hi @christine33-creator, |
|
Thank you for your contribution! We will review the pull request and get back to you soon. |
|
The git hooks are available for azure-cli and azure-cli-extensions repos. They could help you run required checks before creating the PR. Please sync the latest code with latest dev branch (for azure-cli) or main branch (for azure-cli-extensions). pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>
|
CodeGen Tools Feedback CollectionThank you for using our CodeGen tool. We value your feedback, and we would like to know how we can improve our product. Please take a few minutes to fill our codegen survey |
Release SuggestionsModule: aks-preview
Notes
|
There was a problem hiding this comment.
Pull request overview
Fixes an aks-preview regression where managedNATGatewayV2 was treated as an unknown outbound type during _get_outbound_type() dynamic completion, causing it to be silently overwritten to loadBalancer before the request was sent to the RP.
Changes:
- Add
managedNATGatewayV2to the “known outbound types” list so it is preserved (not defaulted toloadBalancer) during create-time dynamic completion. - Extend outbound-type validation to reject
managedNATGatewayV2when using Basic load balancer SKU. - Extend the multi-zone NAT Gateway update warning to also apply to
managedNATGatewayV2.
| if ( | ||
| self.decorator_mode == DecoratorMode.CREATE and | ||
| not read_from_mc and | ||
| outbound_type not in [ | ||
| CONST_OUTBOUND_TYPE_MANAGED_NAT_GATEWAY, | ||
| CONST_OUTBOUND_TYPE_MANAGED_NAT_GATEWAY_V2, | ||
| CONST_OUTBOUND_TYPE_USER_ASSIGNED_NAT_GATEWAY, |
There was a problem hiding this comment.
Consider adding/adjusting unit tests to cover the regression fixed here: when the user explicitly sets --outbound-type managedNATGatewayV2, _get_outbound_type() should preserve it (not default to loadBalancer), and enable_validation should reject it when load balancer SKU is basic. There are existing unit tests for _get_outbound_type() but none exercise the V2 outbound type path.
FumingZhang
left a comment
There was a problem hiding this comment.
Is there an existing test case that covers this scenario to confirm the fix is correct? If not, please create one and schedule the live test to ensure it works as expected.
6aff0ee to
14d28f4
Compare
Added a unit test in test_managed_cluster_decorator.py that verifies managedNATGatewayV2 is preserved through the dynamic completion logic instead of being overwritten to loadBalancer. The test passes locally. A live test cannot pass yet because the RP-side feature toggle is not enabled; the RP currently returns |
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
FumingZhang
left a comment
There was a problem hiding this comment.
lgtm
Please leave a note about the fix in HISTORY.rst
14d28f4 to
eb73cb3
Compare
| @@ -13,6 +13,7 @@ Pending | |||
| +++++++ | |||
There was a problem hiding this comment.
bump the version to 19.0.0b29?
eb73cb3 to
3a4a9b0
Compare
…to loadBalancer The dynamic completion logic in _get_outbound_type() did not include managedNATGatewayV2 in its list of known outbound types. When a user specified --outbound-type managedNATGatewayV2, the CLI treated it as an unrecognized value and silently overwrote it to loadBalancer before sending the request to the RP. Fixed in 3 places: - Dynamic completion list: preserve managedNATGatewayV2 instead of overwriting to loadBalancer - Basic LB SKU validation: reject managedNATGatewayV2 with basic SKU - Multi-zone warning: show zone-redundancy warning for V2 on update
The dynamic completion logic in _get_outbound_type() did not include managedNATGatewayV2 in its list of known outbound types. When a user specified --outbound-type managedNATGatewayV2, the CLI treated it as an unrecognized value and silently overwrote it to loadBalancer before sending the request to the RP.
Fixed in 3 places:
This checklist is used to make sure that common guidelines for a pull request are followed.
Related command
General Guidelines
azdev style <YOUR_EXT>locally? (pip install azdevrequired)python scripts/ci/test_index.py -qlocally? (pip install wheel==0.30.0required)For new extensions:
About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update
src/index.jsonautomatically.You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify
src/index.json.