test: use preview API for Essentials SKU validation

[Ketki Naik (ketkimnaik)]

Summary

• regenerates the enablement and instance deployment templates for preview Essentials SKU validation
• uses the 2026-09-01-preview IoT Operations management API in both generated ARM resources and the direct management client
• updates generated extension and connector expectations for the selected preview deployment contract
• keeps the existing upgrade migration test focused on migration behavior when the preview default spans more than two minor versions

Dependency and scope

• Depends on feat: add Essentials SKU create support #950 and targets its dedicated test branch.
• Test-only validation change; do not merge this PR into dev.
• VERSION remains 2.10.0 and AIO_RELEASE remains 2609 intentionally.

Generation provenance and intentional overrides

• Generated from the local azure-iot-operations-tests branch preview/v1.6.x/2610 at commit 6e1521ebb4893f2db20b4d97187c5ff9c211326f.
• The local source was stale: the remote branch was at 1dfac78ed54a68cd5458c8d6311ada02514428e3. This was explicitly accepted for this test-only PR.
• The source AIO version 1.6.0-preview.11 was deliberately overridden to 1.6.0-preview.9.
• Preview connector registry values (aioconnectorsdev.azurecr.io) were deliberately retained.
• Generated output was produced through Bicep compilation and tools/template_optimizer.py; generated Python was not hand-edited.

Validation

• 375 focused orchestration tests passed
• 244 instance resource tests passed
• flake8 passed
• git diff --check passed
• embedded enablement and instance dictionaries exactly match optimized generated JSON
• verified no $fxv Helm payload remains embedded
• verified connector tag and registry substitutions against source values

[ZZ (zzcodework)]

Azure SRE Agent - automated review

Reviewing full diff (head dee35f7)

Scope note: this PR is stacked on #950, so 7eea1030 ("Add Essentials SKU create support") is the same code I reviewed on #950. I did not re-derive it here — the findings there still apply to this branch, and one of them (the aioInstance apiVersion being too old for sku) is what this PR fixes. Everything below is about this PR's own commit dee35f70. No prior review comments existed on either PR.

Blocking

1. The connectors registry override reaches the ARM/Helm path but not the Python path, so az iot ops upgrade and the az iot ops update OPC UA backfill will stamp an alpha tag against MCR.
   azext_edge/edge/providers/orchestration/common.py moves OPCUA_CONNECTOR_VERSION to 1.4.0-alpha.164, and the template gains CONNECTORS_CHART_REGISTRY / CONNECTORS_IMAGE_REGISTRY defaulting to aioconnectorsdev.azurecr.io. But the sibling constants in the same file are untouched:

   • OPCUA_CONNECTOR_REGISTRY = "mcr.microsoft.com"
   • OPCUA_CONNECTOR_METADATA_REF = "mcr.microsoft.com/azureiotoperations/aio-connectors/opcua-metadata"

   ConnectorTemplates.create_default_opcua_template (providers/orchestration/resources/connector_templates.py) builds connectorMetadataRef = f"{OPCUA_CONNECTOR_METADATA_REF}:{connector_version}" and containerRegistrySettings.registry = OPCUA_CONNECTOR_REGISTRY with tag = connector_version. Its two callers both pass the new alpha value: upgrade2.py (the upgrade-side default template creation, and the two console lines that print the version) and Instances.update's OPC UA backfill (resources/instances.py, connector_version=OPCUA_CONNECTOR_VERSION).
   So on this branch: create pulls connectors from the dev ACR, while upgrade / update create a connector template pointing at mcr.microsoft.com/azureiotoperations/aio-connectors/opcua-metadata:1.4.0-alpha.164 and supervisor tag 1.4.0-alpha.164 on MCR. If that alpha tag is only published to aioconnectorsdev.azurecr.io (which the template change implies), those templates are unpullable. Either add preview-scoped registry constants alongside the version, or confirm the alpha tag is mirrored to MCR.

Suggestions

2. The PR description's rationale for the test_upgrade2_unit.py change is not the rule being hit. 1.4.112 → 1.6.0-preview.9 is minor_diff == 2, which passes the if minor_diff > 2 check in _validate_version_upgrade (upgrade2.py). What actually blocks it is the last guard in the same method: current_is_preview or desired_is_preview → "Upgrades to or from non-stable release trains are not supported.", because the bundled train moved stable → integration. Worth correcting in the body, and worth stating the consequence: on this branch every az iot ops upgrade against an existing stable instance requires --force, and adding .set_user_kwargs(force=True) to that scenario means no test now exercises the non-forced path against the bundled default.

3. enableGdsManager (new bool, defaultValue: True) replaces disableOpcUaFeature as the template's only extra toggle, but a repo-wide grep finds zero references to enableGdsManager / gdsManager outside template.py, and InitTargets.param_to_target (targets.py) does not supply it. So connectors.values.gdsManager.enabled is true for every deployment from this branch with no CLI way to turn it off. Fine if that is the intended preview default; if it needs a switch, it needs a param_to_target entry too.

4. DEFAULT_IOTOPS_MGMT_API_VERSION moves a second time in this stack — feat: add Essentials SKU create support #950 set 2026-10-01, this commit sets 2026-09-01-preview, leaving IoTOpsMgmtApiVersion.V20261001 unreferenced on the branch. Two asks:

   • Confirm 2026-09-01-preview surfaces sku on both GET and LIST, because feat: add Essentials SKU create support #950's new int assertions (instance_show["sku"]["name"] and the same field from az iot ops list) now run against this version, not 2026-10-01.
   • Leave a note for whoever unwinds this branch that dropping the preview default must restore 2026-10-01, not 2026-07-01 — otherwise the SKU read path silently regresses.

5. test_instance_resource_api_versions_match_client_default is a useful guard, but it hard-couples the ARM resource apiVersion to the read client's default, which are not inherently the same thing — any future PR bumping one alone now fails. That is exactly the behaviour you want on this branch; a one-line comment saying so would stop someone "fixing" it later by relaxing the assertion.

Nits

6. The template.py diff mixes a lot of pure formatting churn (line-splitting of "None": {...}, metadata: {"description": ...}, tls: {...}) with the semantic changes. Generated output, so unavoidable — but the semantic set is small enough to enumerate in the body (apiVersions ×8, VERSIONS/TRAINS, connectors registry variables, disableOpcUaFeature → enableGdsManager, removal of effectiveFeatures/opcUaFeatureMode, the three new defaultAioConfigurationSettings keys). The body already covers provenance well; the semantic list would make the review faster.

7. aioconnectorsdev.azurecr.io and train integration are now baked into the bundled blueprint. The body says "do not merge into dev" — given the branch name is not obviously protected, a DO NOT MERGE label on the PR would be cheap insurance.

Checked and clean (recording the negatives so they are not re-derived):

• Removing disableOpcUaFeature is safe. A repo-wide grep for disableOpcUaFeature / disable_opcua across *.py and *.yml returns nothing outside template.py, and InitTargets's param_to_target never supplied it — so no caller breaks and no ARM "undefined parameter" error is possible.
• The OPC UA suppression path still works end to end. properties.features now binds parameters('features') directly, and the opcUaConnectorTemplate condition was rewritten to not(equals(coalesce(tryGet(variables('opcUaFeature'), 'mode'), 'Stable'), 'Disabled')), which is logically identical to the removed opcUaFeatureMode for the only value the CLI could ever produce (disableOpcUaFeature == false). feat: add Essentials SKU create support #950's Essentials override still lands, because _apply_essentials_sku rewrites the --feature list before InitTargets parses it into parameters('features').
• The connector-version guard test still holds: OPCUA_CONNECTOR_VERSION in common.py and the OPCUA_CONNECTOR_VERSION literal inside the ARM variables block both moved to 1.4.0-alpha.164, which is what test_upgrade2_unit.py's "tag stamped by the template" guard compares.
• The new api-version test covers the whole surface: all eight Microsoft.IoTOperations/* resources in TEMPLATE_BLUEPRINT_INSTANCE (aioInstance, broker, brokerAuthn, brokerListener, dataflowProfile, dataflowEndpoint, artifactRegistryEndpoint, opcUaConnectorTemplate) moved to 2026-09-01-preview in this commit, so the all(...) assertion is not vacuous and would catch a missed one.
• The vendored-client mismatch is not new here. vendor/clients/iotopsmgmt/__init__.py exports only v20260701 and get_iotops_mgmt_client forwards api_version as a kwarg, so 2026-09-01-preview is a wire-level override of routes generated from 2026-07-01 — the same arrangement feat: add Essentials SKU create support #950 introduced, not something this commit worsens.
• EXTENSION_CONFIGS in test_template_unit.py was updated consistently with the VERSIONS/TRAINS change in both blueprints (cert-manager 1.2.0, secret-store 1.5.5, ops 1.6.0-preview.9/integration).

Summary: the regeneration looks faithful and well-documented, and the one blocking item is the half-applied registry redirection — the template points connectors at the dev ACR while the Python-side connector-template builders still hardcode MCR with the new alpha tag.

This is an automated review and may be incomplete; please verify findings before acting on them.