Skip to content

{AKS} Add FlexNodes support - #10186

Open
Thalia Wang (wenxuan0923) wants to merge 7 commits into
Azure:mainfrom
wenxuan0923:flexnodes-support
Open

{AKS} Add FlexNodes support#10186
Thalia Wang (wenxuan0923) wants to merge 7 commits into
Azure:mainfrom
wenxuan0923:flexnodes-support

Conversation

@wenxuan0923

@wenxuan0923 Thalia Wang (wenxuan0923) commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

🤖 PR Validation — ❌ Action needed

Breaking Changes
❌ 1
❌Azure CLI Extensions Breaking Change Test
❌aks-preview
rule cmd_name rule_message suggest_message
1010 - ParaPropUpdate aks machine add cmd aks machine add update parameter spot_max_price: updated property default from nan to nan please change property default from nan to nan for parameter spot_max_price of cmd aks machine add
⚠️ 1006 - ParaAdd aks machine add cmd aks machine add added parameter labels
⚠️ 1006 - ParaAdd aks machine add cmd aks machine add added parameter max_pods
⚠️ 1006 - ParaAdd aks machine add cmd aks machine add added parameter node_taints
⚠️ 1006 - ParaAdd aks machine update cmd aks machine update added parameter kubernetes_version
⚠️ 1001 - CmdAdd aks nodepool get-bootstrap-data cmd aks nodepool get-bootstrap-data added

Summary

  • add FlexNodes node pool lifecycle support, including bootstrap data and Kubernetes upgrades
  • add FlexNode Machine create and update support with minimal supported payloads
  • validate operation-specific options while preserving existing regular Machines behavior
  • redact bootstrap credentials in recordings and release aks-preview 21.0.0b14

Testing

  • FlexNodes live lifecycle in eastus2euap: passed
  • refreshed cassette replay: passed
  • affected unit tests: passed
  • full aks-preview suite: 1177 passed, 119 skipped; 9 existing cassette transport failures reproduced on origin/main
  • existing regular Machines recording tests: passed
  • azdev style aks-preview: passed
  • index tests: 7 passed, 2 skipped
  • aks-preview 21.0.0b14 wheel build: passed

Copilot AI lite review requested due to automatic review settings August 6, 2026 01:37
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

@a0x1ab

Copy link
Copy Markdown
Member

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 2 pipeline(s).

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/upgrade and introduce az aks nodepool get-bootstrap-data (marked sensitive).
  • Add FlexNode-aware az aks machine add/update behavior, 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.

Comment thread src/aks-preview/azext_aks_preview/custom.py
Comment on lines +88 to +93
raise InvalidArgumentValueError(
"The following options are not supported for FlexNodes pools: {}. "
"Supported FlexNodes pool options are: {}.".format(
", ".join(unsupported_options), ", ".join(supported_parameters.values())
)
)
@yonzhan

Copy link
Copy Markdown
Collaborator

AKS

@a0x1ab

Copy link
Copy Markdown
Member

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 2 pipeline(s).

@FumingZhang FumingZhang left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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):

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Queued live test to validate the change.

@wenxuan0923 Thalia Wang (wenxuan0923) Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still necessary? I believe the validation at line 2535 already rejects all parameters unsupported by FlexNodes.

@wenxuan0923 Thalia Wang (wenxuan0923) Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/aks-preview/azext_aks_preview/machine.py
Comment thread src/aks-preview/azext_aks_preview/machine.py Outdated
@wenxuan0923

Copy link
Copy Markdown
Contributor Author

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.

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 az aks nodepool and az aks machine` commands.

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
@a0x1ab

Copy link
Copy Markdown
Member

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 2 pipeline(s).

@FumingZhang

Copy link
Copy Markdown
Member

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 2 pipeline(s).

@a0x1ab

Copy link
Copy Markdown
Member

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 2 pipeline(s).

@FumingZhang

Copy link
Copy Markdown
Member

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?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants