Destroy Loganalytics workspace results in soft-deleted workspace

[bgelens]

Hello!

• Vote on this issue by adding a 👍 reaction
• To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already)

Issue details

As I'm developing my stack, I often destroy and start over. A log analytics workspace is part of my stack. When I destroy the stack, the workspace seems to be deleted but once I try to deploy again, I get a ghost resource in the portal and all dependent resources fail as the workspace is actually not available. Turns out that the workspace is not really destroyed but instead "soft-deleted".

I needed to recreate the workspace using PowerShell so it was recovered and then in the Azure Portal had to delete the workspace and tick the checkbox that I want it permanently deleted

Only now I could do a pulumi up again.

AFAIA there is no way to manipulate the destroy operation of a loganalytics workspace. Also there is no recover option as there is with the keyvaults.

Expected: The workspace to be "really" destroyed. Actual: Spend a couple of hours trying to figure out why my pulumi up did not work and had to resort to other tooling to get into deployable state again.

[mikhailshilkov]

Thank you for reporting this @bgelens and sorry for the trouble.

This is "by design" in a sense that we trust Azure API to do the right kind of deletion by default. Our common recommendation is to use the auto-naming feature to make sure that every new resource gets a random suffix to avoid conflicts like the one you hit.

We will use this issue to track potential improvements, e.g. adding opt-in options to force hard-delete, in line with https://github.com/pulumi/pulumi-azure-native/issues/1174

[PawelStadnicki]

Just want to say that auto-naming feature is often not possible due to the chosen, well-managed naming conventions for resources. This is especially the case when Pulumi was adopted when the resources volume is already very mature.

Auto-naming also doesn't play well with Get|ListXXX.InvokeAsync methods.

[mikhailshilkov]

Auto-naming also doesn't play well with Get|ListXXX.InvokeAsync methods.

Could you give an example? You'd have to put InvokeAsync inside Apply but I expect you need to do so for manually-named resources too. Also, you could use the Invoke variant to get rid of the Apply.

[PawelStadnicki]

Correct, mostly for manually-named resources but also for reading resources created with another stacks ( we don't use the stack references feature). And for some other automations like gathering (listing) all access keys /authorization rules and sending them to clients from isolated programs.

[RomanDvorsky]

This is "by design" in a sense that we trust Azure API to do the right kind of deletion by default. Our common recommendation is to use the auto-naming feature to make sure that every new resource gets a random suffix to avoid conflicts like the one you hit.

Hi, I would recommend going a different way - letting people decide and giving them an option to choose.

We want to start with Pulumi - our infrastructure is quite a mess to set all aligned. One part of it is the resources naming conventions, particularly casing. Due to this feature, we are not able recreate given resources properly and we either must give up on Pulumi or we must delete wrong resources manually. In a scope ~1000 resources not wonderful job. And no, we do not want to use auto naming feature due to other automations, scripts using the naming conventions already in place - simply we cannot redo everything we have to do one by one.

[cermakp]

This is "by design" in a sense that we trust Azure API to do the right kind of deletion by default. Our common recommendation is to use the auto-naming feature to make sure that every new resource gets a random suffix to avoid conflicts like the one you hit.

Hi, while the auto-naming feature can be useful, it is not always the best solution. For example, Azure storage account names have a character limit, so adding additional characters can further reduce the number of available characters for naming. Additionally, when importing existing resources, the resource names are already predefined and suffixes cannot be added.