[Question/Feedback]: Should we add a new shared interface to all resource modules for service group association

[jtracey93]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Description

@Azure/avm-core-team-technical

Service groups are going to be the next big thing that customers use to group resources together to aggregate data for monitoring, cost and other purposes as defined here https://learn.microsoft.com/en-us/azure/governance/service-groups/overview#example-scenarios

We have module proposals for service groups as resource modules for both languages here:

• Bicep - [Module Proposal]: avm/res/management/service-group #2323
• Terraform = [Module Proposal]: avm-res-management-servicegroup #2307

Proposal

What I am proposing here is that we add a new shared interface to all resource modules to allow all resources as this is an extension resource, like role assignments etc. as shown here: https://learn.microsoft.com/en-us/azure/governance/service-groups/create-service-group-member-rest-api#create-in-rest-api

Interface input code samples

Bicep

module storageAccount 'br/public:avm/res/storage/storage-account:0.26.2' = {
  params: {
    name: 'stgacc001'
    serviceGroupTargetIds: [
      '/providers/Microsoft.Management/serviceGroups/foo'
      '/providers/Microsoft.Management/serviceGroups/bar'
    ]
  }
}

Terraform

module "avm-res-storage-storageaccount" {
  source  = "Azure/avm-res-storage-storageaccount/azurerm"
  version = "0.6.4"

  name                = "stg-acc-001"
  resource_group_name = "rsg-001"
  location            = "uksouth"

  service_group_targets = {
    "foo" = {
      id = "/providers/Microsoft.Management/serviceGroups/foo"
    },
    "bar" = {
      id = "/providers/Microsoft.Management/serviceGroups/bar"
    }
  }
}

cc: @hlokensgard for input also

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the AVM Issue Triage documentation.

[hlokensgard]

@jtracey93 This makes sense to me.
Just to clarify: you're only referring to adding the membership link Microsoft.Relationships/serviceGroupMember, which ensures that resources are added to the service group. The creation of the service group itself should still be handled as a separate resource as this module suggest.

How about also having the option to add a list of existing resources directly into the service group? I can see scenarios where you'd want to extract a list of resources and add them to a service group without modifying each resource's configuration. That would require those resources to already exist in the code. If you've got some click-ops resources, it might be easier to just include them in the service group. Not sure if that should be its own resource module or added like in my example.

[jtracey93]

Hey @hlokensgard

Correct it's only the membership link for the shared interface.

For creating a service group and also adding a list of resources/scopes to a service group I am planning to add this as an optional input to the service group resource module.

Thoughts?

[hlokensgard]

@jtracey93 Then I completely agree. The solution fits both use cases I’ve considered for working with service groups.

We’re aligned on the approach for adding multiple resources into service groups. That’s exactly how I’ve implemented it in my module.

[AlexanderSehr]

Sounds like a good idea @jtracey93 🚀

[jtracey93]

@AlexanderSehr Bicep PRs are here:

• feat: add service group interface for bicep #2338 (docs)
• feat: add serviceGroupTargetResourceIds to utl common types module bicep-registry-modules#6013 (utl module update)