Check if resource exists

[lordlinus]

feature request
currently creating AKS cluster using Microsoft.MachineLearningServices/workspaces/computes is not idempotent and will error if the link already exists. Currently there is no convenient way to check if the resource already exists and would like to understand the best way to handle this scenario in Bicep

Docs Link: https://docs.microsoft.com/en-us/azure/machine-learning/how-to-create-attach-kubernetes?tabs=python#limitations

Describe the solution you'd like
Convenient way to check if the resource exists and skip certain action ( in this case dont try to establish link) . This could be achieved using a deployment script az cli to see if the resource exists, but looks heavy for a simple check

[bengavin]

This would be a great feature, certain things (like KeyVault secrets) end up getting constantly overwritten with a 'new' value when things like an externally managed secret value are involved. I'd like to be able to create the secret if it's not there, and otherwise just leave it as-is. The 'existing' function doesn't seem to help here, as it just bombs out if you try to use it in this way, stating that the resource doesn't exist.

[alex-frankel]

In theory, due to the idempotent nature of ARM Template/Bicep deployments, you shouldn't need to know if it is new or existing. The AKS issue is definitely a service-side bug. I will send this to them.

@bengavin -- this should be true for the keyvault secret as well. As long as the secret value is the same, the update would be a NoOp. What issue is the update causing?

[bengavin]

@alex-frankel My specific issue is that I need to know the secret exists, I don't want to actually control the value of the secret in the bicep template. I've worked around this by just passing in the list of existing secrets into the template and conditioning the creation on the input parameter vs. the resource itself.

For background, these secrets are for things that likely need rotation by operations staff and they are referenced by web apps, function apps, etc. The goal of the template is to get the secrets setup, with 'tbd' values and linked with the appropriate resources to avoid typos and such. The operations folks can go in and supply the appropriate secret values into KeyVault and have them picked up automatically by the applications. Then, when code changes occur, those secret values are NOT overwritten with 'tbd' values again, since my desired state represents 'exists' vs. 'has this value'.

In my case, introducing another level of indirection by having the secrets looked up during deployment of the template (via KeyVault reference parameter) adds another 'step' into the rotation of secret values that feels unnecessary. I don't want my operations folks to need to update a 'deployment' key vault and then trigger a re-deployment to get the new secret value pushed into the application level key vault.

That said, if this is the wrong approach, I'd be happy to hear that and understand why :)

[miqm]

+1 on this. I'd also like to have a function on ARM/bicep to check if particular resourceId exists.

My use case is that I'd like to create a blue-green deployment of container instance and manipulate private DNS entry to switch to opposite configuration after the deployment. the DNS entry would also indicate which one is currently in use. However, on first deployment, I need to do a fallback (DNS entry will not exist). I could do this with tags, but DNS would be more accurate.

[pabelanger]

Just hitting this now, with key vaults. I think I'm going to test running a pre-run deployment script and probe the keyvault API to see if a vault is in soft delete state or not. If so, then bump the name from kv-test-001 to kv-test-002.

[minhdn90]

+1. We need this too. Deploying Synapse workspace with encryption requires knowing if one already exists to control Key Vault access policy

[jakelevinez]

Would love this - our use case is deploying a VM and putting the admin password into a keyvault - if the VM already exists we don't want to overwrite the value in the vault as it isn't actually applied to the VM.

[WhitWaldo]

In theory, due to the idempotent nature of ARM Template/Bicep deployments, you shouldn't need to know if it is new or existing. The AKS issue is definitely a service-side bug. I will send this to them.

@bengavin -- this should be true for the keyvault secret as well. As long as the secret value is the same, the update would be a NoOp. What issue is the update causing?

If one attempts to recreate a role assignment with the same properties, it yields an error "Tenant ID, application ID, principal ID, and scope are not allowed to be updated. (Code:RoleAssignmentUpdateNotPermitted)." Given they use an idempotent GUID based on these unchanged values, it would be ideal to have some mechanism by which to check whether the role assignment already exists before attempting to set it again, knowing that attempting to set an existing such role will fail the deployment.

[jakelevinez]

@WhitWaldo I have an open ticket with MS about that particular case with roleassignments - even with the same GUID the deployment will fail if you don't wait long enough between deplyments (on the order of days). If you wait a few days between deployments, it does work.

@alex-frankel I can speak to the secret issue - you can't have it deploy the same secret value, because if you can generate that value again, you've in some way hardcoded your value into your template. Proper secret generation would use something like the newGuid() function which won't allow you to create the same secret value, for obvious security reasons.

[brwilkinson]

@jakelevinez

I just noticed your comment, you can likely avoid the error by adding the property 'principalType'

It is documented here:
https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-template#new-service-principal

[jlevine-aba]

@brwilkinson Unfortunately it looks like in my case we are already doing ServicePrincipal and on a relatively recent preview API version, must be something different affecting us.

[brwilkinson]

@jlevine-aba okay, well worth a try, hopefully support can sort you out then.

only other tip to slow deployments down to buy you some time is to put batchsize(1) on your module loops. That may give the assignments enough time to replicate since they go in series... hard to say without all of the details, however support should be able to provide guidance.

[mdarefull]

Joining this thread this time also because of KeyVault. My issue is that the KeyVault resource requires the access policies array to be provided, which means that if I deploy the resource, all my access policies are overridden. Only deploying KeyVault if it doesn't exist feels like the lesser evil although far from ideal.

I understand that in theory, ARMs should be idempotent, but in practice, many resources are not. I think this team should be pragmatic and add support to this feature to make adoption easier. I'm confident we'll see fewer and fewer issues in the future as the industry matures more, but we are quite not there yet.

[miqm]

@alex-frankel just another case that we NEED to check if a resource exists. For using aks and application gateway ingress controller.
The thing is that if we do first time deployment we might need to put some default routes at the beginning. Then, when we deploy pods to AKS and AGIC is enabled, it will override AGW configuration to whatever is set in pods. Since AGW routes, listeners, etc are not resources but properties, next deployment of our template will clear the configuration made by AGIC making our services in AKS loose it’s ingress connectivity. So we need to either deploy AGW manually and keep it outside ARM or have a condition to check if we have the AGW already created.
Also, if we can determine that resource exists, we can call a module on that condition to get the current configuration and do a merge with some additional routes we want to add to not disturb things added by AGIC.

[brwilkinson]

@miqm I think this one would be better if the backend Rules were actually a standalone property that would allow you to not overwrite these settings, which would be similar to the NATRules on a Load balancer or the App Configuration settings on a Web Site. linking to the open issue on this as well #2316

[olafloogman]

There's a way to accomplish this by using deployment scripts. I've created a Bicep module to check whether a resource exists, which can be found here: https://github.com/olafloogman/BicepModules/blob/main/resource-exists.bicep

There's the additional overhead of needing to run the script in a container instance, but according to MS docs:
Deployment script execution is an idempotent operation. If none of the deploymentScripts resource properties (including the inline script) are changed, the script doesn't execute when you redeploy the template.

[abatishchev]

+1, here's my scenario:

I want to use reference() on VMSS auto-scale settings and adjust the VMSS template accordingly if the auto-scale settings resource already exists, and create it with default value if it does not yet (a region buildout scenario)

[WithHolm]

My suggestion on the issue that was closed is a simple "exists?". This way you either get the existing resource or a null, like parameters are already handled.

[zebslc]

Another use case is B2C. Once I have set up a b2c environment, I can't create another (which is correct). Unfortunately bicep doesn't work that out automatically so I have to hack it with the powershell scripts to work out whether it does. This basic exists requirement has been around now for a couple of years. Is it even on the roadmap yet?

I would also love bicep to automatically revive a soft deleted key-vault rather than erroring that it can't create a new one.

If I have an environment that I tear down when it's no longer needed and then recreate and keyvault was in the original setup, it fails because I have to hard delete or restore it manually

[alex-frankel]

We are considering building support for this as part of the next semester of work. Will know more by the end of March.

[zebslc]

Surely you must already have this internally to be able to work out whether to replace or create a new item so it should just be a case of surfacing that...

[alex-frankel]

@zebslc - we do not actually. Bicep/Template Deployments naively redeploy all resources in the template (by design) and we rely on the Resource Providers to handle the PUT call as gracefully as possible.

[WithHolm]

@alex-frankel bicep might not have this, but checking resource existance is a possible management operation https://learn.microsoft.com/en-us/rest/api/resources/resources/check-existence?view=rest-resources-2021-04-01

[jikuja]

Other view for that API endpoint: https://learn.microsoft.com/en-us/rest/api/resources/resources/check-existence-by-id?view=rest-resources-2021-04-01

Checks by ID whether a resource exists. This API currently works only for a limited set of Resource providers. In the event that a Resource provider does not implement this API, ARM will respond with a 405. The alternative then is to use the GET API to check for the existence of the resource.

[alex-frankel]

Right, we don't lack the ARM APIs to add this functionality. I was just pointing out that it's not as if we are already doing this today and choosing not to expose it to bicep devs.

[WithHolm]

@alex-frankel

We are considering building support for this as part of the next semester of work. Will know more by the end of March.

we are past the end of march. you have any updates for us?

[alex-frankel]

This is currently planned to be implemented in the current semester (4/1 - 9/30). However, the design of this is not complete. Once we have closed on design, we can provide a more precise and accurate ETA.

[lhardy-scs]

Great to see this functionality is being added. I believe I'm hitting a similar issue with the SQLVirtualMachine extension on redeployment as I'm getting the error 'Volume with drive letter F already exists' as it appears to be trying to initialise a disk as F whereas that was already done in the initial deployment. I'll be raising a ticket for this as I would like to be able to redeploy the extension without issue, however the ability to just skip that extension for now without having to use a bool (I do that for key vault keys at the moment) would be much appreciated

[chrisklingsater]

Great to see that this is on it's way to being implemented! Just chipping in here that the event hub with a system-assigned identity and encryption through customer-managed keys isn't idempotent either.

We have to deploy the event hub without encryption first to get the identity and deploy the correct role assignment, then we have to update the bicep file with the encryption object. Otherwise the deployment fails because it's forbidden by Azure RBAC as the event hub doesn't (yet) have permission to access the key vault, since the role assignment hasn't been deployed yet.

That process works perfectly when deploying CosmosDB with CMK and the correct role assignment though. so I'm sure it will get corrected by the Event Hub team at some point, hopefully.

@alex-frankel Any updates on the ETA?

[mmaitre314]

Adding a scenario: deploying Synapse Spark clusters is not fully idempotent -- packages can only be specified starting from the second cluster deployment. The initial cluster creation needs to happen without packages.

[acortelyou]

@alex-frankel Is this feature still in the blackhole backlog?

[dirkslab]

Ran into an issue last night and was thinking and told a colleague about how 'check if exist' could have solved my issue. Low and behold someone commented about this feature request right after:) This one still on my wish list.

[andrew-from-toronto]

Microsoft.KeyVault/vaults/keys is not idempontent, just running into this now.