{AKS} Add FlexNodes support - #10186
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
This PR extends the aks-preview extension to add preview support for FlexNodes across nodepool lifecycle operations (create/update/upgrade/bootstrap data) and introduces FlexNode machine add/update flows using minimal supported payloads, along with recording redaction and a version bump to 21.0.0b14.
Changes:
- Add FlexNodes support to
az aks nodepool add/update/upgradeand introduceaz aks nodepool get-bootstrap-data(marked sensitive). - Add FlexNode-aware
az aks machine add/updatebehavior, including operation-specific option validation. - Add redaction support for bootstrap credentials in test recordings and update extension version/history.
Reviewed changes
Copilot reviewed 19 out of 20 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/aks-preview/setup.py | Bumps extension version to 21.0.0b14. |
| src/aks-preview/HISTORY.rst | Documents new FlexNodes functionality and other fixes in 21.0.0b14. |
| src/aks-preview/azext_aks_preview/_consts.py | Adds CONST_FLEX_NODES. |
| src/aks-preview/azext_aks_preview/_validators.py | Extends --vm-set-type validation to accept FlexNodes. |
| src/aks-preview/azext_aks_preview/agentpool_decorator.py | Adds FlexNodes vm set type mapping + option validation and payload trimming for FlexNodes pools. |
| src/aks-preview/azext_aks_preview/_helpers.py | Introduces user-supplied option detection + FlexNodes option validation helper. |
| src/aks-preview/azext_aks_preview/custom.py | Adds FlexNodes behavior for nodepool upgrade/bootstrap data and FlexNode machine add/update paths. |
| src/aks-preview/azext_aks_preview/machine.py | Adds FlexNode minimal machine payload construction and improves label parsing robustness. |
| src/aks-preview/azext_aks_preview/commands.py | Registers aks nodepool get-bootstrap-data as a sensitive command. |
| src/aks-preview/azext_aks_preview/_params.py | Adds FlexNode machine arguments (labels/taints/max-pods; kubernetes-version on update). |
| src/aks-preview/azext_aks_preview/_help.py | Adds help for get-bootstrap-data and documents FlexNodes options/examples. |
| src/aks-preview/azext_aks_preview/tests/latest/test_validators.py | Adds unit coverage for FlexNodes vm-set-type validation. |
| src/aks-preview/azext_aks_preview/tests/latest/test_agentpool_decorator.py | Adds decorator-level coverage for FlexNodes vm-set-type and add-time option validation. |
| src/aks-preview/azext_aks_preview/tests/latest/test_update_agentpool_profile_preview.py | Adds update-time validation coverage for FlexNodes supported/unsupported options. |
| src/aks-preview/azext_aks_preview/tests/latest/test_helpers.py | Adds unit coverage for validate_flexnodes_options. |
| src/aks-preview/azext_aks_preview/tests/latest/recording_processors.py | Redacts bootstrap token + CA cert data in recordings. |
| src/aks-preview/azext_aks_preview/tests/latest/test_recording_processors.py | Adds unit tests for the new recording redaction behavior. |
| src/aks-preview/azext_aks_preview/tests/latest/test_custom.py | Adds unit coverage for FlexNodes pool upgrade rules and FlexNode machine add/update behavior. |
| src/aks-preview/azext_aks_preview/tests/latest/test_aks_commands.py | Adds a live test that exercises supported FlexNodes operations end-to-end. |
| raise InvalidArgumentValueError( | ||
| "The following options are not supported for FlexNodes pools: {}. " | ||
| "Supported FlexNodes pool options are: {}.".format( | ||
| ", ".join(unsupported_options), ", ".join(supported_parameters.values()) | ||
| ) | ||
| ) |
|
AKS |
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
FumingZhang
left a comment
There was a problem hiding this comment.
My overall concern is that this approach has become fragile. Since FlexNodes supports only a small subset of existing node pool and machine options, integrating it into the existing command groups requires extensive validation, payload filtering, and special-case branching to prevent unsupported parameters from being used.
Would a dedicated FlexNodes subcommand group provide a clearer and more maintainable interface? It could expose only supported operations and parameters, reduce the risk of accidentally sending incompatible fields, produce clearer help and error messages, and avoid repeatedly updating exclusion lists whenever existing commands gain new options.
I understand that reusing existing commands offers consistency and may preserve the expected CLI resource model, but I think the long-term maintenance and compatibility trade-offs are worth considering before expanding this pattern further.
| @AKSCustomResourceGroupPreparer( | ||
| random_name_length=17, name_prefix="clitest", location="eastus2euap" | ||
| ) | ||
| def test_aks_flexnodes_supported_operations(self, resource_group, resource_group_location): |
There was a problem hiding this comment.
The gate failed because its alternate subscription had AKSFlexNodePreview unregistered and overrode the scenario location to westus2. Fixed in 472ff2c: the scenario now idempotently registers and polls both required features, re-registers Microsoft.ContainerService to propagate them, and preserves eastus2euap. The updated live test and cassette replay both passed.
Queued a new live test here: https://dev.azure.com/msazure/CloudNativeCompute/_build/results?buildId=175510820&view=results
|
|
||
| # Blue-green upgrade settings | ||
| if not instance.upgrade_settings_blue_green: | ||
| blue_green_settings = (drain_batch_size, drain_timeout_bg, batch_soak_duration, final_soak_duration) |
There was a problem hiding this comment.
Is this still necessary? I believe the validation at line 2535 already rejects all parameters unsupported by FlexNodes.
There was a problem hiding this comment.
Yes this guard is still necessary because validation only rejects explicitly supplied unsupported options. The generic path below backfills AgentPoolBlueGreenUpgradeSettings() whenever the GET response has no blue-green profile, which would otherwise add unsupported upgradeSettingsBlueGreen: {} to a FlexNodes PUT even when the user supplied no blue-green options.
Thanks FumingZhang, That's a good point. We considered a nested FlexNodes group, but the current command shape follows the approved PRD to reuse the existing The supported surface is small today because this is the initial preview. We expect it to grow as we work toward feature parity, so a dedicated subgroup may become mostly duplicated commands and parameters over time. The implementation is fail-closed: each operation has a positive allow-list, and payload builders emit only supported fields. New options are rejected automatically until we explicitly add them to the FlexNodes allow-list, so future features added to the existing commands are less likely to accidentally flow into FlexNodes requests. I agree we should keep consolidating the internal routing rather than adding scattered special cases. Is the subgroup a blocker for this PR, or something we can revisit if the resource model diverges further? |
…into flexnodes-support # Conflicts: # src/aks-preview/HISTORY.rst
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
The subgroup isn’t a blocker—just my two cents. Since this is a preview extension, it’s also a good opportunity to gather customer feedback before deciding whether it should eventually move to a subgroup. |
🤖 PR Validation — ❌ Action needed
❌Azure CLI Extensions Breaking Change Test
Summary
Testing