azure-cli: APIM gets stuck in soft-delete state

Describe the bug A soft-delete feature was recently added to API management, and is only available through the preview version of the REST API. The documentation linked above states that using the azure CLI to delete an API Management instance will result in hard delete behavior. This is true, for the az apim delete command.

However, deleting the entire resource group with az group delete puts any existing APIM resources into the soft-deleted state, so those resources cannot be redeployed (due to naming collisions) until the deleted resource expires or is purged. The purge functionality is only available through the preview version of the REST API, so it seems like the new soft-delete shouldn’t affect the CLI tool.

To Reproduce

  1. Create a new resource group
  2. Create an API management instance inside that resource group
  3. Use az group delete to delete the resource grop
  4. Use the REST API to list soft-deleted services, and notice that the API management instance is listed

Expected behavior Using az group delete has the same affect on the api management instance as az apim delete

Environment summary CLI version: 2.14.2 (installed with apt-get) OS version: Windows 10 build 19042.630 Shell type: Bash on windows (WSL 1)

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 13
  • Comments: 37 (1 by maintainers)

Most upvoted comments

@miaojiang More important to the “az apim delete” options, we need CLI (and PowerShell) commands that we can use to discover, purge and restore soft-deleted APIM instances. APIMs will get deleted using a variety of mechanisms, including deleting via the portal. Currently, the only option we have to do this is using the REST API. I’m glad to discover “az rest” can be used for that, but it’s not the best option as it requires us to maintain knowledge of yet another toolset.

Just stumbled across this today while testing a Bicep template to deploy APIM. So after learning Bicep/ARM to create resources, and PowerShell/CLI to also…create and delete resources. we now need to figure out how to use REST to purge APIM instances?

How many different technologies do we need to learn to support Azure?

Same here, constantly having to rename stuff just to avoid this “feature”

What the hell is going on Microsoft, When a DevOps deletes something we know What we are doing, Don’t try to treat us like a amateur common user, take of this damn bloody feature please

This is a crappy feature. Been fighting this for a few hours trying to purge hidden resources.

Very poor developer experience, Microsoft. Who came up with that??

The solution for me was to first list the deleted instance to get the required details and for the purge, using az rest like pointed out by stvdilln above.

Login using az login in the console.

Then az rest --method get --header "Accept=application/json" -u 'https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.ApiManagement/deletedservices?api-version=2021-08-01' to list the details of the soft deleted apim service.

Then delete it using the following, making sure to add the correct location in the url (e.g. westeurope or eastus): az rest --method delete --header "Accept=application/json" -u 'https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.ApiManagement/locations/{location}/deletedservices/{apim-name}?api-version=2020-06-01-preview'

Surprisingly, this took only a second to execute. Much less than the hour I wasted trying to figure out what the hell is going on and how to fix it…

Soon this issue will complete a whole year. This is a really bad design choice, soft delete being on preview should be optional and not lock you behind the rest api.

Come on Microsoft - we depend on you. This ‘feature’ is poorly documented & half-implemented. This approach comes at a real cost to us, your partners. Do better!

Thank you all for the feedback. We are considering adding an option to az apim delete to control whether soft delete should be applied.

still considering? after over a year?

Another day which could’ve been productive work.

Another day wasted for me as well.

Wasted a day on this - how on earth was this feature silently enabled, without requiring an opt-in, without an easy way to purge the soft-deleted instances, which leads to a day searching through out-of-date Microsoft docs that gives partial clues…?

+1 - me and my customer encountered the same challenge - looking forward to a better experience

Thanks for reporting the issue. We will review.

cc @KedarJoshi @RupengLiu

We’ve just deployed an APIM instance using API version Microsoft.ApiManagement/service@2019-12-01 - We’re seeing soft delete applied when we’ve deleted this resource through the portal. Was under the impression this was only a feature in the new preview version 2020-06-01-preview ?

Seems the 2019-12-01 version does not include the property “restore” so unsure why it’s applying soft delete?

A soft-deletion also occurs if you explicitly decide to delete the APIM instance from a resource group through the Portal. This should be communicated more clearly.

Complete joke this still isn’t sorted

This is beyond a joke now, I managed to purge a key vault in soft delete yesterday using the CLI, why not implement the same functionality for APIM? 🤯

re out how to use REST to purge APIM instances? az rest --method delete --header "Accept=applicaiton/json" -u 'https://management.azure.com/subscriptions/{SubscriptionId}/providers/Microsoft.ApiManagement/locations/{eastus}/deletedservices/{api name}?api-version=2020-06-01-preview'

Based on the amount of time several of the features surrounding the apims have been left in preview I wouldn’t be surprised if Azure rolls back the whole apims feature so you’re probably better off switching to some other provider or using a third party if you want apims functionality.

still not fixed and still non reaction this is a shame

That worked, but it was much more painful that having a button on the portal or a CLI or PowerShell command.

This totally broke our infrastructure automation for several projects 😠