Being able to reference resources across modules?

[anthony-c-martin]

There's a lot of useful stuff you can do once you have a symbolic reference to a resource - property access, proper type validation, deploying extension resources, deploying child resources, and probably some other things I'm not thinking of. This is at odds with reference() and resourceId(), which give you untyped objects and strings respectively.

It's great that we have these capabilities within one file, but it feels a bit limiting that they are confined to within that file. This limits my ability to modularize my code.

For example being able to define a reusable template that deploys an extension resource:

// main.bicep

resource myParent 'My.Rp/parent@2020-01-01' = {
  ...
}

module deployExtensions './extensions.bicep' = {
  ...
  params: {
    // pass the ref to the parent
    parent: parent
  }
}

// access the ref for the extension resource
var extensionRef = deployExtensions.outputs.extension1

// extensions.bicep

// mockup for a resource reference parameter
param parent resource<'My.Rp/parent@2020-01-01'>

// access properties from parent with type safety
var myParentProp = parent.properties.foo

// deploy an extension resource
resource extension1 'My.OtherRp/extension@2020-01-01' = {
  scope: parent
  ...
}

// mockup to output the resource reference
output myExtension resource<'My.OtherRp/extension@2020-01-01'> = extension1

Just wanted to start a discussion to see if this is potentially interesting to anyone, there are any potential other use-cases that I haven't thought of, or workarounds to do something similar today!

[majastrz]

I think overall the scenario is super useful and we should support it. One big unknown in my mind right now is how we approach visibility of exported resources. Do we make that explicit or do we just expose everything? Based on feedback, I think we have users in both camps.

[rob-byram]

Yes, utilizing the output variable does what I need it to do. Very short recap:
within main.bicep:

module databaseAccount 'cosmosaccount.bicep' = {
  name: 'databaseAccountDeployment'
  params: {
    accountName: accountName
    [other necessary params]    
  }
}

module db './nosqldatabase.bicep' = [for database in databases: { //databases being an object parameter I passed in
  name: 'db_${database.name}'
  params: {
    parentName: databaseAccount.outputs.outAccountName //since this is an output from first module, bicep will wait until that is complete before processing this module
    database: database
  }
}]

[rob-byram]

I see your dependsOn comment, that is probably the better answer, but now I know there are a couple of ways to do it.

Learnin'!!

[brwilkinson]

@rob-byram looks good.

[brwilkinson]

You can also call the database module directly from the Cosmos module. Or Containers from the Database.

• However that just depends how you want to structure your data for your parameters to match Child resources.

  E.g. https://github.com/brwilkinson/AzureDeploymentFramework/blob/dev/ADF/tenants/ABC/ACU1.T5.parameters.json#L1364

[stijnherreman]

It's unfortunate that 3.5 years later there's only an experimental flag for a first step. Early 2022 the initial implementation was estimated to happen "in the next few months".

I'm only just getting started with simple modules and cross-subscription resources, and it's already a drag. How come there is no (visible) movement? Are there people saying "nah this isn't important enough compared to feature X and Y"? Is there scope creep, trying to rework too many things at once while losing sight of the goals of this issue?