Feature request | break the glass ability to destroy a DevCenter and all dependent resources

[lopezleandro03]

It's cumbersome, nearly impossible to destroy DevCenters that depend on Projects that depend on Environments. Sometimes these environments depend on catalog items that no longer exists or have changed which makes it hard to delete ending up in a lot of trash in the dev portal.

Would be great to have some sort of garbage collector / purge functionality that cleans up idle / orphan / broken environments (like a soft deletion of keys in AKV). This might not be desired once thins are up & running but would definitely speed up the exploration and piloting phase. An optional feature.

Would be great to have the ability to delete a DevCenter and all dependent resources in a forced manner. "Danger Zone" type of functionality.

[KarsonAlford]

I am finding that the DevCenters are getting out of synch very easily. I am trying to clean up the existing ones so I can start all over. I cannot delete the projects because there are environments that users cannot access. I cannot delete the DevCenter because it thinks the projects still have data. I can't delete the resource group for the same reason. This is a very severe issue.

I am going to try putting in a support ticket with Microsoft to delete all these resources.

[markl234]

Had same experience. Tried everything to delete each resource but still telling me there's something dependent.

[John-Donalson]

any process of which to follow to delete enviornments and projects??? Does there need to be a specific order in which you do it?

[KarsonAlford]

Working with Microsoft we were finally able to get everything deleted.

Some Background: We are using an AD group for users and managed identities that need Owner access to the subscription. I had the DevCenter system assigned identity as a user in the group for months and did not run into any issues until 2 weeks ago.

Two weeks ago, we created a second DevCenter with some of our developers with access to just one DevCenter and others with access to both. This was when everything got corrupted, and we couldn't delete environments from the devportal and there was no option in the DevCenter.

After everything got corrupted, I started cleaning up all the permissions including removing the DevCenter identities from the AD group so we wouldn't end up with 'Identity not found' placeholders everywhere.

Working With Microsoft: While trying to figure out how to delete the DevCenters we tried several Azure CLI commands, and nothing worked. This week one of the DevCenters (was apparently upgraded) began allowing environment deletes from the portal UI. This also didn't work.

Microsoft had me re-add the system assigned identities for the DevCenters as Owner for the subscription. This worked [only when we assigned the system assigned identity to the subscription and not to the AD group (not sure if this is a red herring or not, we didn't test this thoroughly).]

The other DevCenter’s environments, projects, and environment types could not be deleted from the UI because some of those options did not show up in the UI. However, using API commands for environments and projects (and portal UI operations for other resource) we were able to clear up those resources once the DevCenter’s identity had Owner access to the subscription.

Example API Commands:

# This command must have the UserId of the user that created the environment and must be ran by that user.
az devcenter dev environment delete --dev-center-name "dc-Feature"  --name "testteam2" --project-name "TeamEnvironments" --user-id "d4cd9ed1-68a9-4566-8159-1459d3b9d2bd"
az devcenter admin project delete --name "Environmental" --resource-group "Dev-DevBox"

Conclusion: At the time of this writing there appears to be two different versions of DevCenters floating around. Both require that the DevCenter’s identity have Owner permissions to the subscription and that you manually delete artifacts in the reverse order they were added.