"az stack-hci-vm network lnet create" fails when tags are included

[Nikkelmann]

Describe the bug

When running az stack-hci-vm network lnet create with --tags myTag="myValue" it fails.
For comparison I tried running az sshkey create and az aksarc create and both work with and without --tags using the same format.

Related command

az stack-hci-vm network lnet create

Errors

CMD-LOG-LINE-BEGIN 25972 | 2025-01-29 16:01:41,061 | INFO | az_command_data_logger | command args: stack-hci-vm network lnet create --name {} --subscription {} --resource-group {} --location {} --custom-location {} --vm-switch-name {} --ip-allocation-method {} --address-prefixes {} --gateway {} --dns-servers {} {} --ip-pool-start {} --ip-pool-end {} --vlan {} --tags {}
CMD-LOG-LINE-BEGIN 25972 | 2025-01-29 16:01:41,151 | INFO | az_command_data_logger | extension name: stack-hci-vm
CMD-LOG-LINE-BEGIN 25972 | 2025-01-29 16:01:41,151 | INFO | az_command_data_logger | extension version: 1.5.0
CMD-LOG-LINE-BEGIN 25972 | 2025-01-29 16:01:41,360 | ERROR | az_command_data_logger | The command failed with an unexpected error. Here is the traceback:
CMD-LOG-LINE-BEGIN 25972 | 2025-01-29 16:01:41,363 | ERROR | az_command_data_logger | Unable to build a model: Unable to deserialize response data. Data: ['createdBy=fel'], {str}
Traceback (most recent call last):
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\_serialization.py", line 1636, in deserialize_data
    return self.deserialize_type[iter_type](data, data_type[1:-1])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\_serialization.py", line 1675, in deserialize_dict
    return {x["key"]: self.deserialize_data(x["value"], dict_type) for x in attr}
            ~^^^^^^^
TypeError: string indices must be integers, not 'str'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\_serialization.py", line 704, in body
    data = deserializer._deserialize(data_type, data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\_serialization.py", line 1472, in _deserialize
    value = self.deserialize_data(raw_value, attr_desc["type"])
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\_serialization.py", line 1647, in deserialize_data
    raise DeserializationError(msg) from err
azure.core.exceptions.DeserializationError: Unable to deserialize response data. Data: ['createdBy=fel'], {str}

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 233, in invoke
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 666, in execute
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 734, in _run_jobs_serially
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 703, in _run_job
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/__init__.py", line 336, in __call__
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 120, in handler
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\generated\custom.py", line 1154, in stackhcivm_logicalnetwork_create
    raise parsed_exception
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\generated\custom.py", line 1149, in stackhcivm_logicalnetwork_create
    response = client.begin_create_or_update(resource_group_name=resource_group_name,
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/core/tracing/decorator.py", line 94, in wrapper_use_tracer
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\operations\_logical_networks_operations.py", line 643, in begin_create_or_update
    raw_result = self._create_or_update_initial(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\operations\_logical_networks_operations.py", line 509, in _create_or_update_initial
    _json = self._serialize.body(resource, "LogicalNetwork")
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\user\.azure\cliextensions\stack-hci-vm\azext_stack_hci_vm\vendored_sdks\stack_hci_vm\v2024_08_01_preview\_serialization.py", line 706, in body
    raise SerializationError("Unable to build a model: " + str(err)) from err
azure.core.exceptions.SerializationError: Unable to build a model: Unable to deserialize response data. Data: ['createdBy=fel'], {str}
CMD-LOG-LINE-BEGIN 25972 | 2025-01-29 16:01:41,367 | INFO | az_command_data_logger | exit code: 1

Issue script & Debug output

az stack-hci-vm network lnet create --name "name" --subscription "subscription" --resource-group "resource-group" --location "westeurope" --custom-location "/subscriptions/GUID/resourceGroups/RGNAME/providers/Microsoft.ExtendedLocation/customLocations/CLNAME" --vm-switch-name '"SWITCHNAME"' --ip-allocation-method "Static" --address-prefixes "x.x.x.x/23" --gateway "x.x.x.x" --dns-servers 0.0.0.0 --ip-pool-start "x.x.x.x" --ip-pool-end "x.x.x.x" --vlan 1 --tags createdBy="fel"

Expected behavior

It should work with --tags included.

Environment Summary

az --version
azure-cli                         2.68.0

core                              2.68.0
telemetry                          1.1.0

Extensions:
aksarc                            1.4.23
connectedk8s                      1.10.4
customlocation                     0.1.3
k8s-runtime                        1.0.4
stack-hci-vm                       1.5.0

Dependencies:
msal                              1.31.1
azure-mgmt-resource               23.1.1

Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\user\.azure\cliextensions'

Python (Windows) 3.12.8 (tags/v3.12.8:2dc476b, Dec  3 2024, 19:30:04) [MSC v.1942 64 bit (AMD64)]

Legal docs and information: aka.ms/AzureCliLegal


Your CLI is up-to-date.

Additional context

No response

[yonzhan]

Thank you for opening this issue, we will look into it.

[github-actions]

Here are some similar issues that might help you. Please check if they can solve your problem.

• --ip-tags failure when used in "az network public-ip create" command #7639

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Azure/deployments-owners.

[anthony-c-martin]

@yonzhan - the "Azure Deployments" tag added is not accurate - we do not manage the "az stack-hci-vm" command group.

I think this configuration is probably the issue:

azure-cli/.github/policies/resourceManagement.yml

Line 6262 in 05a5d8f

pattern: (az deployment|az bicep|az stack|az deployment-scripts|az ts|az group export)

We do own the az stack command group
We don't own the az stack-hci-vm command group

[torreymicrosoft]

Thanks for your patience — this was recently picked up while reviewing open issues routed to the ARM Deployments team.

A routing note first: as @anthony-c-martin flagged here, this one landed on the ARM Deployments queue by mistake. The az stack-hci-vm command group (the stack-hci-vm CLI extension) isn't owned by our team — we own az stack (deployment stacks), but az stack-hci-vm belongs to the Azure Local / Azure Stack HCI team, and its code lives in the azure-cli-extensions repo.

On the bug itself: the traceback is a serialization error in the extension's vendored SDK — --tags createdBy="fel" is reaching the request builder as a list of key=value strings (['createdBy=fel']) where a { "key": "value" } map is expected, which is why az sshkey/az aksarc accept --tags but lnet create doesn't. That's an extension-side fix.

We're going to re-route this to the stack-hci-vm extension owners (and drop the ARM Deployments labels) so the right team can fix the tag serialization. Thanks for the clear repro — apologies for the bounce.