azure-cli: az vmss diagnostics set --resource-group --vmss-name --settings router_config.json --protected-settings protected.json gives error The value of parameter type is invalid.

az feedback auto-generates most of the information requested below, as of CLI version 2.2.0-1

Describe the bug az vmss diagnostics set cli gives error"The value of parameter type is invalid."

To Reproduce Steps to reproduce the behavior. Run the command

  • az vmss diagnostics set --resource-group <rg> --vmss-name <vmss> --settings router_config.json --protected-settings protected.json

Expected behavior Enable LinuxDiagnostic on VM scale set

Environment summary Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)

Docker container - VERSION=" Ubuntu 18.04.4 LTS (Bionic Beaver)"

Additional context Add any other context about the problem here.

It used to work on a older version of az cli 2.0.66

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 21 (9 by maintainers)

Most upvoted comments

Looks like Azure CLI version 2.2.0 forgot to pass the extension’s type to the underlying Resource Provider.

eg. with CLI 2.1.0 “extensions”: [ { “name”: “customScript”, “properties”: { “autoUpgradeMinorVersion”: true, “publisher”: “Microsoft.Azure.Extensions”, “type”: “CustomScript”, “typeHandlerVersion”: “2.0”, “settings”: {“commandToExecute”:“echo testing”} }

and with CLI 2.2.0 “extensions”: [ { “name”: “customScript”, “properties”: { “autoUpgradeMinorVersion”: true, “publisher”: “Microsoft.Azure.Extensions”, “typeHandlerVersion”: “2.0”, “settings”: {“commandToExecute”:“echo testing”} }

I have opened a PR to fix this issue. The root cause is that Python SDK abandoned type. Instead, it uses type1 now. I am very confused why there is such kind of change!!!

    def __init__(self, *, name: str=None, force_update_tag: str=None, publisher: str=None, type1: str=None, type_handler_version: str=None, auto_upgrade_minor_version: bool=None, settings=None, protected_settings=None, provision_after_extensions=None, **kwargs) -> None:
        super(VirtualMachineScaleSetExtension, self).__init__(**kwargs)
        self.name = name
        self.type = None
        self.force_update_tag = force_update_tag
        self.publisher = publisher
        self.type1 = type1

@diepes - unfortunately CloudShell doesn’t include the latest CLI version with the fix. This should be deployed in ~2 weeks from what I hear.

I have the same issue with CLI 2.2.0, see also at https://github.com/MicrosoftDocs/azure-docs/issues/50180

az vmss extension set
–resource-group $managed_rg
–vmss-name $vmss_name
–name VMAccessForLinux
–publisher Microsoft.OSTCExtensions
–version 1.4
–verbose
–debug
–protected-settings “{"username":"azureuser", "ssh_key":"$(cat ~/.ssh/id_rsa_aks_vm.pub)"}”

az --version azure-cli 2.2.0

command-modules-nspkg 2.0.3 core 2.2.0 nspkg 3.0.4 telemetry 1.0.4

Extensions: aks-preview 0.4.38 azure-firewall 0.3.0

Python location ‘/opt/az/bin/python3’ Extensions directory ‘/home/pinpin/.azure/cliextensions’

Python (Linux) 3.6.5 (default, Mar 6 2020, 14:41:24) [GCC 7.4.0]

Legal docs and information: aka.ms/AzureCliLegal

I’m observing same issue for az vmss extension set --vmss-name akswin1 --resource-group MC_something --publisher Microsoft.Powershell --name DSC --version 2.9.1 --settings @./settings.json --protected-settings @./psettings.json --force-update when running that in Azure Cloud Shell.

Version info:

{
  "azure-cli": "2.2.0",
  "azure-cli-command-modules-nspkg": "2.0.3",
  "azure-cli-core": "2.2.0",
  "azure-cli-nspkg": "3.0.4",
  "azure-cli-telemetry": "1.0.4",
  "extensions": {
    "aks-preview": "0.4.35",
    "front-door": "1.0.3",
    "resource-graph": "1.0.0"
  }
}