Update vmSize and/or add workaround for unsupported sizes in locations & zones

[ShawnMcGough]

I received the following error when deploying acr-stamp. It took me a bit to workout a vmSize that would work.

"The template deployment failed with error: 'The resource with id: '/subscriptions/x/resourceGroups/rg-bu0001a0008/providers/Microsoft.Compute/virtualMachineScaleSets/aks-npuser01-37152336-vmss' failed validation with message: 'The requested size for resource '/subscriptions/x/resourceGroups/rg-bu0001a0008/providers/Microsoft.Compute/virtualMachineScaleSets/aks-npuser01-37152336-vmss' is currently not available in location 'eastus2' zones '1,2,3' for subscription 'x'. Please try another size or deploy to a different location or zones. See https://aka.ms/azureskunotavailable for details.'.'.\"}

Maybe just a callout in the doc that explains this could happen with the default vmSize, and a change might be required to the acr-stamp.bicep file.

[ckittel]

Sorry to hear that. Yeah, as MSFT employees, we do have some size and region restrictions placed on us -- they come and go it seems. Just like Azure Policy interference, we can't do much about it. I know it sucks to get so far. I wonder if the right option wouldn't be a quick az CLI command to check the availability of the SKUs in the region before running the deployment. Would you like to add a PR to do that?

[ShawnMcGough]

How does this command look?

It should filter out all SKUs that have restrictions as well as other capability filters.

az vm list-skus --location eastus2 --resource-type virtualMachines --query '[?!restrictions && capabilities[?name==`OSVhdSizeMB` && to_number(value)>=`122880`] && capabilities[?name==`EphemeralOSDiskSupported` && value==`True`] && capabilities[?name==`vCPUsAvailable` && to_number(value)==`4`]].{Name:name, Size:size, Family:family}'  --output table

I ended up using Standard_D4lds_v5 for both scale sets, as the Standard_D2lds_v5 didn't have enough disk space (despite the response indicating it should).