{AKS} az aks cluster: Update high log scale cnl logic

[carlotaarvela]

This PR automatically enables High Log Scale Mode (HLSM) when Container Network Logs (CNL) is specified in az aks create and az aks update commands.

Changes:

When --enable-container-network-logs is specified, --enable-high-log-scale-mode is automatically set to true
Raises MutuallyExclusiveArgumentError if user explicitly sets --enable-high-log-scale-mode false while enabling CNL
Validates that ACNS and monitoring addon are enabled when using CNL
Updated help text to document the auto-enablement behavior

Testing:

Added 15 unit tests covering CREATE and UPDATE scenarios
Manual testing performed with live Azure clusters

---

This checklist is used to make sure that common guidelines for a pull request are followed.

Related command

az aks cluster create --enable-container-network-logs --enable-acns --enable-addons -a monitoring --enable-high-log-scale-mode
az aks cluster update --enable-container-network-logs --enable-acns --enable-addons -a monitoring --enable-high-log-scale-mode

General Guidelines

• Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
• Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
• My extension version conforms to the Extension version schema

For new extensions:

• My extension description/summary conforms to the Extension Summary Guidelines.

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.json automatically.
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.

[azure-client-tools-bot-prd]

️✔️Azure CLI Extensions Breaking Change Test

️✔️Non Breaking Changes

[azure-client-tools-bot-prd]

Hi @carlotaarvela,
Please write the description of changes which can be perceived by customers into HISTORY.rst.
If you want to release a new extension version, please update the version in setup.py as well.

[yonzhan]

Thank you for your contribution! We will review the pull request and get back to you soon.

[github-actions]

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).
After that please run the following commands to enable git hooks:

pip install azdev --upgrade
azdev setup -c <your azure-cli repo path> -r <your azure-cli-extensions repo path>

[github-actions]

CodeGen Tools Feedback Collection

Thank 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

[github-actions]

• For more info about extension versioning, please refer to Extension version schema

[carlotaarvela]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 9530 in repo Azure/azure-cli-extensions

[Copilot]

Pull request overview

This PR automatically enables High Log Scale Mode (HLSM) when Container Network Logs (CNL) is specified in az aks create and az aks update commands. The implementation adds validation to ensure that prerequisites (ACNS and monitoring addon) are met and prevents users from explicitly disabling HLSM while enabling CNL.

Changes:

• Auto-enables --enable-high-log-scale-mode when --enable-container-network-logs is specified
• Validates that ACNS and monitoring addon are enabled when using CNL
• Updates help text to document the auto-enablement behavior

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
setup.py	Version bump to 19.0.0b21
HISTORY.rst	Added changelog entry for the auto-enablement feature
_help.py	Updated help text for --enable-container-network-logs and --enable-high-log-scale-mode to document auto-enablement
custom.py	Changed default value of enable_high_log_scale_mode parameter from False to None to allow distinguishing between unspecified and explicitly disabled
managed_cluster_decorator.py	Implemented get_enable_high_log_scale_mode override with auto-enablement logic and validation; added validation triggers in set_up_addon_profiles and update_monitoring_profile_flow_logs
test_managed_cluster_decorator.py	Added 15 comprehensive unit tests covering CREATE and UPDATE scenarios, error cases, and auto-enablement behavior

[yonzhan]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[FumingZhang]

Queued live test to validate the change.

• test_aks_create_with_monitoring_aad_auth_msi
• test_aks_create_with_monitoring_aad_auth_uai
• test_aks_create_with_monitoring_aad_auth_msi_with_syslog
• test_aks_create_with_monitoring_aad_auth_msi_with_datacollectionsettings
• test_aks_create_with_monitoring_aad_auth_msi_with_datacollectionsettings_and_otheraddon
• test_aks_create_with_monitoring_aad_auth_uai_with_syslog
• test_aks_create_with_private_cluster_with_monitoring_aad_auth_msi_with_ampls
• test_aks_create_with_monitoring_aad_auth_with_highlogscale
• test_aks_create_with_private_cluster_with_monitoring_aad_auth_msi_with_ampls_with_highlogscale

[FumingZhang]

I noticed that most of the other --enable-xxx options related to the monitoring addon are also declared as arg_type=get_three_state_flag(), in that case, the default value of them should all be set to None. Could you please fix this?

[carlotaarvela]

I have fixed enable_syslog. I believe this is the only option that needed updating

[FumingZhang]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[FumingZhang]

Queued live test to validate the change.

• test_aks_create_with_monitoring_aad_auth_msi
• test_aks_create_with_monitoring_aad_auth_uai
• test_aks_create_with_monitoring_aad_auth_msi_with_syslog
• test_aks_create_with_monitoring_aad_auth_msi_with_datacollectionsettings
• test_aks_create_with_monitoring_aad_auth_msi_with_datacollectionsettings_and_otheraddon
• test_aks_create_with_monitoring_aad_auth_uai_with_syslog
• test_aks_create_with_private_cluster_with_monitoring_aad_auth_msi_with_ampls
• test_aks_create_with_monitoring_aad_auth_with_highlogscale
• test_aks_create_with_private_cluster_with_monitoring_aad_auth_msi_with_ampls_with_highlogscale

Re-queued live test, all tests now failed with the following error

E Code: InvalidOutputTable
E Message: Table for output stream 'Microsoft-KubeMonAgentEvents' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Target: properties.dataFlows[0] (InvalidOutputTable) Table for output stream 'Microsoft-InsightsMetrics' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Code: InvalidOutputTable
E Message: Table for output stream 'Microsoft-InsightsMetrics' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Target: properties.dataFlows[0] (InvalidOutputTable) Table for output stream 'Microsoft-ContainerInventory' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Code: InvalidOutputTable
E Message: Table for output stream 'Microsoft-ContainerInventory' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Target: properties.dataFlows[0] (InvalidOutputTable) Table for output stream 'Microsoft-ContainerNodeInventory' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Code: InvalidOutputTable
E Message: Table for output stream 'Microsoft-ContainerNodeInventory' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Target: properties.dataFlows[0] (InvalidOutputTable) Table for output stream 'Microsoft-Perf' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Code: InvalidOutputTable
E Message: Table for output stream 'Microsoft-Perf' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Target: properties.dataFlows[0] (InvalidOutputTable) Table for output stream 'Microsoft-ContainerNetworkLogs' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Code: InvalidOutputTable
E Message: Table for output stream 'Microsoft-ContainerNetworkLogs' is not available for destination 'la-workspace'. Please ensure that the table exists in Log Analytics Workspace before creating or updating the rule.
E Target: properties.dataFlows[0]

Test passed based on the last commit!

[FumingZhang]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[yanzhudd]

please resolve the code conflicts

[carlotaarvela]

@yanzhudd I have resolved the conflicts and update the version
Could you trigger the tests and merge? Thanks

[yanzhudd]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[FumingZhang]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[FumingZhang]

Hi @carlotaarvela, @ShantingLiu helped find a issue about the validation flow

test test_enable_container_network_logs (Case 4 in test_managed_cluster_decorator.py). It happens because of an operator precedence bug in get_container_network_logs() validation - the condition evaluates as (enable_cnl AND acns_not_enabled) OR monitoring_not_enabled, which errors if monitoring isn't configured regardless of enable_cnl. Additionally, during cluster create, mc.addon_profiles is empty even when --enable-addons monitoring is passed, so the validation fails.

This is her proposed solution for additionally checking the input from --enable-addons. Could you please review it and see if it should be adopted?
https://github.com/Azure/azure-cli-extensions/pull/9575/changes#diff-5d84e24288452ee31a88191a8f27887756d7cab78ed51be901e9d6ffabc70e2aR965-R976