azure-cli
azure-cli copied to clipboard
Add wait/no-wait support to Commands
PR #1463 added support for the ... wait command for select command groups and the --no-wait option for several long-running operations in those groups. This issue is for identifying and tracking which commands still need this functionality exposed. Please nominate additional commands to be given wait/no-wait capability in the comments.
Needed
- [ ] acr repository delete
- [ ] postgres server firewall-rule create/delete
- [ ] provider register [issue #1910] (from @yugangw-msft we probably can live with it, as it is not a common op)
- [ ] storage file|blob copy (i.e. wait until a copy operation is finished) [issue #1787]
Completed
- [x] sql server create (PR #9022)
- [x] cdn endpoint purge (PR #8792)
- [x] container start/restart (PR #8600)
- [x] snapshot create (PR #7836)
- [x] local-gateway create/update/delete (PR #2524)
- [x] express-route create/update/delete (PR #2524)
- [x] vnet-gateway ~~create~~/~~update~~/delete (PR #2524)
- [x] vmss ~~create~~/update/delete/start/stop/deallocate/... (PR #2524)
- [x] vm delete/deallocate/start/stop/... (PR #2524)
- [x] vm user (PR #2524)
- [x] vm create/update (PR #1463)
- [x] group delete (PR #1463)
- [x] group deployment create (PR #1463)
- [x] application-gateway create/update/delete (PR #1463)
- [x] vnet-gateway create/update (PR #1463)
- [x] az disk commands (PR #3390)
- [x] network nic create (PR #6684)
- [x] vm extension set (PR #6684)
- [x] group deployment delete (PR #6684)
This is needed for end of Sprint 12 right? cc: @johanste, @yugangw-msft
Removed milestone as this is an additive change.
I would think this is not really a GA-mandatory item. It would simply be an additive feature we can incrementally roll out over time. This issue is to track those items for which it would be nice to have.
Please add support for "az vm access" as well, the command took minutes to complete, it's practically not possible to manage large set of VMs without --no-wait.
I'd love to get --no-wait on az disk delete
I would really like to get --no-wait for "az network nic create" and "am vm extension set" commands.
az group deployment delete --no-wait would be great, ATM there's no way to async delete a batch of deploys, have to serially do it one by one and it takes a long time.
I have a customer request for --no-wait on az snapshot create. Thanks!
@tjprescott, have we handled all asks here?
@yugangw-msft this issue is intended not to be closed. It is intended for users to comment when there are new commands they want wait/no-wait support for.
Can we have --no-wait on az container start and az container stop? It is already supported when creating containers, but not when restarting an existing one.
@geoning I don't see any instance when az container stop is a long running operation. az container start can be. Is there a particular image you use that makes container stop long-running?
Does az container stop wait until the container has gracefully stopped? Because you can never know what the container does when it receives a SIGTERM. In my use case, I don't need no-wait on stop, I just mentioned to keep it consistent.
A no-wait flag on az cdn endpoint purge would be great, too. :-) Currently my deployment pipeline waits over 5 minutes for purging a single asset... :-(
I would like --no-wait on
az sql server create
It will be very handy to have it available for
az acr repository delete
az postgres server firewall-rule create and az postgres server firewall-rule delete could use the same flag. I'm provisioning a PgSQL db with firewall rules from azure devops and from the ~8 mins pipeline run time ~4 are just to set 5 firewall rules
If possible, please add "az sig" to the list
I need wait for az acr network-rule add. It is not a long running operation, but it's long enough to fail in my use-case. I'm using terraform to a list of outbound IP addresses from an app service to the existing list of on-premise IPs. Terraform doesn't support modifying that list after creation of the acr (see https://github.com/terraform-providers/terraform-provider-azurerm/issues/4936). So I'm using a null resource with a provisioner. But it launches all the az commands without waiting, and so some of them fail with "Error: Error running command 'az acr network-rule add --name registryname --ip-address xxx.xxx.xxx.xxx': exit status 1. Output: ERROR: Another operation is in progress for the resource /subscriptions/****/resourceGroups/rg-name/providers/Microsoft.ContainerRegistry/registries/registryname. Please try after some time."
Need a wait option on: az network dns zone delete
I keep my zone data in the flat file format to feed internal DNS servers. The delete can take a few seconds or several minutes for a 400 record zone. Obviously do not want zone down long. THX.
Please add the ability to --no-wait for az postgres db delete
Please add --no-wait support for az image delete?
I need a wait option for storage account. I'm having issues creating a container right after the storage account is created using az cli.
#!/usr/bin/env bash
az storage account create \
--name "samassimoarm" \
--resource-group "rgMassimoTf" \
--location "South Central US" \
--default-action 'Allow' \
--sku Standard_LRS
while true; do
PROVISIONED=`
az storage account show \
--name "samassimoarm" \
--resource-group "rgMassimoTf" \
--query [provisioningState] \
--output tsv
`
[[ $PROVISIONED == 'Succeeded' ]] && break
done
CONNECTION_STRING=`
az storage account show-connection-string \
--name "samassimoarm" \
--resource-group "rgMassimoTf" \
--output tsv
`
az storage container create \
--name "arm-templates" \
--account-name "samassimoarm" \
--connection-string "$CONNECTION_STRING"
az vm run-command needs --no-wait option.
Example command:
az vm run-command invoke -g rgName -n vmName --no-wait --command-id RunPowerShellScript --scripts @c:\temp\run_this_script.ps1
@sdavis3 If you have new requirements, please create a feature request. We will arrange our development plan according to the priority.
I'd also like to nominate az sql db import/export for a no-wait But, I would highly suggest to actually add this flag as an option to all existing commands as a global parameter.
Flagged in #23885
What about mandating wait support for any API that returns 202?
I do not understand how this issue can be open for 8 years.