Consider defaulting required 'location' to 'resourceGroup().location'

[pakrym]

In a lot of simpler deployment scenarios, customers would want to deploy resource groups and all the resources to be in the same location. It also creates friction for new customers that need to figure out why each resource needs to have its own location and what to set it to.

Proposal

Default the required 'location' property of resources to 'resourceGroup().location'

Before

resource singleResource 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: '${name}single-resource-name'
  location: resourceGroup().location
}

After

resource singleResource 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: '${name}single-resource-name'
}

Analyzer

We can also add an analyzer that prompts users to remove the redundant qualification.

Happy to do the work if you decide this feature is something you are interested in.

[alex-frankel]

In the past, we've discussed the ability to opt-in to specific defaults. I'm not sure it's appropriate to make the default behavior of bicep include a default like this.

It would be interesting if we could have this as a provider setting once we have the ability to configure a provider:

import az {
  defaults: {
    location: resourceGroup().location
  }
}

import kubernetes {
  defaults: {
    meta: {
      foo: 'bar'
    }
  }
}

[pakrym]

Do you have some context on why the original decision to make 'location' required for every resource was made by the ARM service team?

[alex-frankel]

I believe it has to do with data sovereignty concerns to ensure that your data for a given resource is stored in a particular geo.

[anthony-c-martin]

Just wanted to point out - there are a few other pieces of underlying complexity to be aware of in particular with location:

• Not all resources support all ARM regions, so we can't generically choose resourceGroup().location and have it work 100%.
• Some resources support special region strings such as global or UnitedStates.
• We don't necessarily have accurate data on which resource types do/don't support location as a property.

[pakrym]

To add another data point, Azure CLI does default the location: https://docs.microsoft.com/en-us/cli/azure/storage/account?view=azure-cli-latest#az_storage_account_create

[WhitWaldo]

Throwing another wrench in this, in what I hope is a very limited exception... BackendAddressPools (under Load Balancers) don't list 'location' on the root and hide it within properties.

[rynowak]

@alex-frankel - the kubernetes example is HOT

import kubernetes {
  defaults: {
    metadata: {
     labels:  {
      foo: 'bar'
     }
    }
  }
}

It would be powerful nice to do something like this with labels as a per-template scope. It maps well to an existing pattern with helm charts. This also would be interesting with tags for ARM resources.

[StephenWeatherford]

Note that I'm implementing one of the TTK rules that resources should use a 'location' parameter instead of resourceGroup().location directly, as a best practice (location: location). All the resource snippets will also now use "location: location" by default. See #2776.