Existing resource based on id (as opposed to name)

[Alxandr]

Is your feature request related to a problem? Please describe.
I have some arm templates where I take in resource IDs (instead of names). While most of these are in the same resource group (and as such, changing to use the name is pretty straight forward), some of them are not, and I then have to split up into providing both a name and a scope.

Describe the solution you'd like
I would like to be able to create an "existing resource" with a resource-id. I suggest allowing the use of the existing syntax with either (name, [scope]) or (id), allowing the following:

@description('Service bus namespace')
param serviceBusNamespaceId string

resource serviceBusNamespace 'Microsoft.ServiceBus/namespaces@2017-04-01' existing = {
  id: serviceBusNamespaceId
}

[miqm]

@anthony-c-martin - something that we've discussed recently :)

[JustinGrote]

I started a discussion as well around this very thing: #1709

[miqm]

Adding for reference - some ideas of declaring existing resource as one-liner I did mention in #127 (comment), could be part of the fix for this issue.

[peter-bertok]

This comes up a lot when wiring up things like storage accounts and log analytics workspace -- they're often created in a different resource group or even a subscription, for various security reasons or just for having consolidation of logs in one place.

This means that most templates would need the full resource ID fed in as a parameter, not a name.

[majastrz]

I think this makes sense. I think we could make this work in bicep fairly easy, but I am wondering if we should have native support for passing resource IDs around in the runtime. This way we would also get runtime enforcement of the IDs. (Which would catch accidentally passing the ID of a wrong type.)

[peter-bertok]

This way we would also get runtime enforcement of the IDs.

I've been advocating for Bicep to have a "strongType" capability vaguely similar to what Blueprints can do.

That would enormously improve the utility of the entire template-based ecosystem. The Portal could provide a much nicer interface (selectors instead of text boxes), PowerShell could tab-complete on the actual resources available, parameters could be validated better, etc...

[alex-frankel]

Closing and tracking with #2245/#2246 which should solve this.

In the meantime, you can use the split() function as a workaround for doing this.

var idToSplit = '/subscriptions/e93d3ee6-fac1-412f-92d6-bfb379e81af2/resourceGroups/alfran-redhat/providers/Microsoft.Compute/virtualMachines/adotfrank-rh'

var splitId = split(idToSplit, '/')

resource existingVm 'Microsoft.Compute/virtualMachines@2021-07-01' existing = {
  scope: resourceGroup(splitId[2], splitId[4])
  name: splitId[8]
}