The following command is based on a code snippet I found in the official documentation to create a Linux Service Fabric cluster.
Originally it was bash script, but that's not available on my private build agents (requires windows insider program??) so I switched to batch script.
I wonder why the following command fails:
d:\a\r1\a>call az sf cluster create --resource-group "ha17aztestclustergroup" --location "westeurope" --certificate-output-folder . --certificate-password "433q6D7sdNKkd-.,6ck#6" --certificate-subject-name "ha17rsomaztestsf.cloudapp.azure.com" --cluster-name "ha17aztestcluster" --cluster-size 3 --os UbuntuServer1604 --vault-name "ha17rsomaztestkeyvault" --vault-resource-group "ha17aztestclustergroup" --vm-password $VmPassword --vm-user-name "sfadmin"
ERROR: az sf cluster: error: argument subcommand: invalid choice: create
usage: az sf cluster [-h]
{select,manifest,code-version,config-version,health} ...
The exact same inline script does work on my private build agents with AZ CLI 2.0.20 installed.
Azure hosted Agents (VS2017) has AZ CLI 2.0.14 installed.
But I doubt that's the problem.
The Hosted VS2017 has Azure CLI 2.0.14 installed, there isn’t create command for az sf cluster (2.0.21 contains), you can check it by adding Azure CLI task with az sf cluster --help command to check its commands.
So, you can setup a private build agent and do build with this agent. Deploy an agent on Windows
I ran into a similar problem whilst deploying a different resource (Function Apps). There was a bug fix in a later version than what was installed on the hosted agents.
I ended up getting around this problem by either dynamically injecting this command into my scripts or by simply having an extra Azure CLI step in my Release to update Azure CLI
pip install --pre azure-cli --extra-index-url https://azurecliprod.blob.core.windows.net/edge
Unfortunately it takes nearly 5 minutes to update the Agent but all of my Releases are reliable now.
Related
I am trying to delete a virtual machine using the command below
az resource delete --ids /subscriptions/0b1f6471-1bf0-4dda-aec3-111111111111/resourceGroups/MyResourceGroup/providers/Microsoft.Network/virtualMachines/vmlname1 --no-wait
I am getting this error:
unrecognized arguments: --no-wait
When I remove --no-wait it works
By this link:
https://learn.microsoft.com/en-us/cli/azure/resource?view=azure-cli-latest#az-resource-delete-optional-parameters
no-wait is given as a valid parameter
--no-wait
Do not wait for the long-running operation to finish.
Can anyone tell me, whether it is possible to use --no-wait in az resource delete ?
Update:
This is the az cli version i am using:
{
"azure-cli": "2.40.0",
"azure-cli-core": "2.40.0",
"azure-cli-telemetry": "1.0.8",
Thanks
It is possible to use the --no-wait flag with the az resource delete command. My testing using the flag did not produce the error that you are seeing. Is it possible that your azure cli is not up to date?
You can upgrade your azure cli to the latest version by following these instructions.
I have reproduced in my environment and got below results:
I have one VM named srivm with Resource ID like below:
When I ran the same command as you to delete VM, I got same error as below:
az resource delete --ids /subscriptions/<subID>/resourceGroups/<rgname>/providers/Microsoft.Network/virtualMachines/<vmname> --no-wait
Response:
Note that, the current version of the Azure CLI is 2.43.0. The error may occur if the CLI version is less than latest version.
When I checked the az version, I got response like below:
To resolve the error, upgrade your CLI version to latest version with az upgrade command or download azure-cli-2.43.0.exe directly.
After installing the latest version, I'm able to delete the VM successfully after running below command:
az resource delete --ids /subscriptions/<subID>/resourceGroups/<rgname>/providers/Microsoft.Network/virtualMachines/<vmname> --no-wait
Response:
To confirm that, I checked Portal and VM deleted successfully like below:
I run following command
az vm create --resource-group MyRG --name myVMName --image windows-11:win11–21h2-pro:22000.376.2112072052
This causes following error.
API version 2022-03-01 does not have operation group 'virtual_machine_images'
I assume this means --image no more support but what's the alternative? Couldn't find anything relevant in the Auzre cli documentation about this. My az cli version seems upto date
az --version
azure-cli 2.37.0
core 2.37.0
telemetry 1.0.6
Extensions:
azure-devops 0.24.0
Dependencies:
msal 1.18.0b1
azure-mgmt-resource 21.0.0
Python location '/usr/bin/python3'
Extensions directory '/home/kali/.azure/cliextensions'
Extensions system directory '/usr/lib/python3/dist-packages/azure-cli-extensions'
Python (Linux) 3.10.5 (main, Jun 8 2022, 09:26:22) [GCC 11.3.0]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Update:
This error is not specific to windows-11, I am getting same error with other OS too. See image below for detailed error.
az vm create --resource-group MyRG --name myVMName --image
windows-11:win11–21h2-pro:22000.376.2112072052
The image version you are using in your cmdlet is not supported. I would suggest you use the below Azure Cli cmdlet to see the list of supported windows-11:win11-21h2-pro images to deploy a virtual machine.
az vm image list --all --offer windows-11 --sku win11-21h2-pro -o table
Below image shows when we ran the above cmdlet from Azure cloudshell:
Below image shows when we ran the above cmdlet from local AzureCLI:
Note: I have tested the above az vm image list cmdlet in local & Azure Cloudshell as well it is working fine,I am able to see the list of support images and their respective versions.
I have ran the below cmdlet, am able to deploy the virtual machine using the image (MicrosoftWindowsDesktop:windows-11:win11-21h2-pro:22000.675.220507).You just need to use the image version that is shown in the above list
az vm create --resource-group <resourcegroupName> --name <vmName> --image MicrosoftWindowsDesktop:windows-11:win11-21h2-pro:22000.675.220507
I have 2 different function apps and deployment scripts. The first app (functionApp1) uses the az cli, and the second one is being written to use the new AZ Powershell modules.
I thought I wouldn't be impacting the az cli solution by installing/setting up the latest powershell cmdlets but I think functionApp1's deployment is broken since installing the new Az Powershell tools.
When I run the az cli deployment script for function App 1, it dies while trying to publish the application. The error message says:
You're trying to use v4 tooling to publish to a non-v4 function app
(FUNCTIONS_EXTENSION_VERSION is set to ~3). You can pass --force to
force update the app to v4, or downgrade tooling for publishing.
Code
In case it helps, here are some snippets of code from the deployment script for functionApp1 The following logic to create a resource group, application insights, and a storage account all works:
az login --service-principal --username $CLIENT_ID --password $SECRET --tenant $TENANT --allow-no-subscriptions
az account set --subscription $SUBSCRIPTION_ID
az group create -n $RESOURCE_GROUP_NAME -l $RESOURCE_LOCATION
az deployment group create --resource-group $RESOURCE_GROUP_NAME --template-file (Join-Path $PSScriptRoot "./resources/function1App.json")
Next I grab information from the new resources I created above, and I update my local.settings.json file. This also still works:
func settings add FUNCTIONS_WORKER_RUNTIME dotnet #explicitly set this.
#auto-update the local.settings.json file with connection string
func azure storage fetch-connection-string $storageAccount.name
#grab contents of local settings file.
$data = Get-Content 'local.settings.json' -raw | ConvertFrom-Json
#logic to update local settings.
Lastly I try to publish the functions in azure using my local settings file. And this is the part that is no longer working:
$functionDeploymentResult = func azure functionapp publish $FUNCTION_APP.name --publish-local-settings -i --overwrite-settings -y
But the error message I'm getting is this:
You're trying to use v4 tooling to publish to a non-v4 function app (FUNCTIONS_EXTENSION_VERSION is set to ~3).
You can pass --force to force update the app to v4, or downgrade tooling for publishing.
I tried to add the --force option and while it gets rid of the error message, when I try to actually run my test "hello world" function in azure, I see the following error message:
Microsoft.Azure.WebJobs.Script: One or more loaded extensions do not meet the minimum requirements. For more information see https://aka.ms/func-min-extension-versions.
ExtensionStartupType AzureStorageWebJobsStartup from assembly 'Microsoft.Azure.WebJobs.Extensions.Storage, Version=4.0.3.0, Culture=neutral, PublicKeyToken=asdfasdfasdf' does not meet the required minimum version of 4.0.4.0. Update your NuGet package reference for Microsoft.Azure.WebJobs.Extensions.Storage to 4.0.4 or later.
AZ CLI VERSION
PS C:\Users\me\Documents\src\functionapp1> az --version
azure-cli 2.30.0 *
core 2.30.0 *
telemetry 1.0.6
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\me\.azure\cliextensions'
Python (Windows) 3.8.9 (tags/v3.8.9:a743f81, Apr 6 2021, 13:22:56) [MSC v.1928 32 bit (Intel)]
Legal docs and information: aka.ms/AzureCliLegal
You have 2 updates available. Consider updating your CLI installation with 'az upgrade'
Please let us know how we are doing: https://aka.ms/azureclihats
and let us know if you're interested in trying out our newest features: https://aka.ms/CLIUXstudy
.vscode/settings.json
{
"azureFunctions.deploySubpath": "src/bin/Release/netcoreapp3.1/publish",
"azureFunctions.projectLanguage": "C#",
"azureFunctions.projectRuntime": "~3",
"debug.internalConsoleOptions": "neverOpen",
"azureFunctions.preDeployTask": "publish (functions)"
}
I'm presently trying to do some research on how / what specifically to downgrade but any tips / suggestions would be appreciated.
Azure PowerShell does not interfere with Azure cli installation.
Based on the error message, it looks like the version of the Azure function tools you are using is v4 but the function app that you have deployed is v3 (likely defined so in the ARM template that you are using).
I want to update size of vmss from Standard_F16s_v2 to Standard_F32s_v2 I usually do it from Ui
but for some requirement I have to do it from a script so I tried to follow the documentation
https://learn.microsoft.com/en-us/cli/azure/vmss?view=azure-cli-latest
and tried to run this command
az vmss update --name MyScaleSet --resource-group MyResourceGroup --vm-sku Standard_F32s_v2
but it is not working shows error UnrecognizedArgumentError: unrecognized arguments: --vm-sku Standard_F32s_v2
The issue was with a previous version of az CLI which was resolved by upgrading it to version 2.30.0.
Test Scenario :
When I try to deploy an Azure Function to the cloud using... func azure functionapp publish appName --build remote --publish-local-settings
...I receive the following error
Getting site publishing info...
Remote build is a new feature added to function apps.
Your function app appName does not support remote build as it was created before August 1st, 2019.
Please use '--build local' or '--build-native-deps'.
For more information, please visit https://aka.ms/remotebuild
EVEN THOUGH THE APP WAS LITERALLY JUST CREATED IN AZURE PORTAL.
System:
- Running VS Code on Ubuntu 18.04
Steps to reproduce:
Create a new Function App (and support resources) using az cli
Python runtime
Consumption plan
StandardV2 Storage plan
AppInsights
Create new Function (scaffolding) using VS Code Azure Functions extension
Create __init__.py and configure local.settings.json
Open a terminal; cd to Function folder
Run func azure functionapp publish appName --build remote --publish-local-settings
Fails everytime with the message above
Tried so far:
- Substituting --build local.
- Looks like it wants to work, but fails with error
There was an error restoring dependencies. ERROR: cannot install cryptography-2.9.2 dependency: binary dependencies without wheels are not supported when building locally. Use the "--build remote" option to build dependencies on the Azure Functions build server, or "--build-native-deps" option to automatically build and configure the dependencies using a Docker container. More information at https://aka.ms/func-python-publish
Not going to try:
- --build-local-deps because I don't want a docker instance for my Function App
Please advise. This is painful at this point.
In my case, I was provisioning an azurerm_linux_function_app with terraform and got this error. The error turned out to be caused by me forgetting to specify the storage_account_access_key setting. The docs even mention
One of storage_account_access_key or storage_uses_managed_identity must be specified when using storage_account_name.
But terraform does not actually check that when applying your configuration, resulting in a cryptic error message much later in the process.
Here is what was found today:
I initially created the Function App Storage Account with...
# Create a Function App Storage Account
az storage account create \
--name $fa_storage_name \
--resource-group $rg_name \
--access-tier Cool \
--default-action Deny \
--kind StorageV2 \
--subscription $az_sub
--location $az_loc \
--sku Standard_LRS
Changed this to...
# Create a Function App Storage Account
az storage account create \
--name $fa_storage_name \
--resource-group $rg_name \
--location $az_loc \
--sku Standard_LRS
...and was able to get past that error. The way I stumbled onto this was using the --buld local flag. It gave me a MUCH MORE ACCURATE error. Something along the lines of Check your storage account dude.
(thank you Marcelo!)