Azure-cli: workspace-resource-id parameter format would be useful to document

[mrdfuse]

I actually had to contact support and they also had some trouble figuring it out, the workspace-resource-id parameter for enabling the monitor addon needs to be in the format: The resourceid should be like this :
/subscriptions/[your sub]/resourcegroups/[your oms rg]/providers/Microsoft.OperationalInsights/workspaces/[your oms workspace name]
and not just the actual id, as the parameter name implies

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d75c3a8d-1187-bea1-a7d4-7ebba71c1790
• Version Independent ID: 75b0c352-762e-16ae-5cc6-d807ffc1dc3f
• Content: az aks
• Content Source: latest/docs-ref-autogen/aks.yml
• Service: container-service
• GitHub Login: @rloutlaw
• Microsoft Alias: routlaw

[tjprescott]

How is that not the actual ID?

[jemag]

I think the confusion stems from the fact that inside the Azure Portal, the "Workspace Id" is given as a simple GUID. However, the az cli needs the "workspace-resource-id" which is more of a URL (like the one provided by mrdfuse).

I do not know if you can actually get it from the portal, I personally found it using the azure cli:
az resource list

[mrdfuse]

Indeed, both me and Azure support thought we had to pass the GUID, as with many other commands in Azure CLI.

[tjprescott]

@mrdfuse @jemag thanks for the clarification.

@mboersma we've added some guidance for parameters that end with -id recently. https://github.com/Azure/azure-cli/blob/dev/doc/command_guidelines.md#argument-naming-conventions

Based on that, -id would imply a GUID is acceptable. When something is an ARM resource ID, we omit the -id in the name and call out in the help text. The main reason is that something which accepts an ARM resource ID should typically be following the "name or ID" convention in the CLI.

https://github.com/Azure/azure-cli/blob/dev/doc/authoring_command_modules/authoring_commands.md#supporting-name-or-id-parameters

In this case, my recommendation would be to expose --workspace (name or ARM ID) and deprecate --workspace-resource-id.

[gaziqbal]

Agreed. Please clarify this. I was also just confused by this.

[brobichaud]

I was unable to get the syntax right after struggling a while too. I'd found it documented two ways and neither worked for me. But I finally figured it out by manually enabling it in the Azure Portal and then noticed the "Workspace resource id" appears in the Properties tab of the ASK Cluster resource. It now works in my cluster creation script script.

[mboersma]

@zqingqing1 @GaneshaThirumurthi @samkreter could someone on the AKS team please take a look?

[palma21]

This is a bit tricky

Workspace name is a field, but won't work here
Workspace ID (GUID) is a field but won't work here
The only thing that works here is workspace resource ID (which was taken from the API I believe)

Having this in mind, I think only workspace or workspace-resource might still be confusing.

Proposals:
1) Improve help text from
_The resource ID of an existing Log Analytics Workspace to use for storing monitoring data._
to
_The ARM resource ID (url) of an existing Log Analytics Workspace to use for storing monitoring data._

2) Rename to workspace-resource-url (and still change the help text)

I prefer 1) as resource-url is not really a term that is familar to Azure I think.

[elygre]

Yup, had trouble with this today. Found the solution not in the documentation, but here, as a documentation bug.