[Bug Report]: Azure Cosmos DB database level shared throughput not respected when creating containers

[markdebruijne]

Describe the bug

When you have configured Throughput/Autoscale on a database level you do so because then containers can use that capacity together.

When using the Azure Portal > Data Explorer blade > Create container > existing database (with throughput configured), by default it creates the container with respecting that shared throughput. You can override it and specify throughput (or autoscale) on that container explicitly if you want to.

Versions

Templates pulled from this repository Monday May 8th 2023
Bicep CLI version 0.17.1
"azure-cli": "2.46.0"

To reproduce

If I use the /Microsoft.DocumentDB/databaseAccounts/main.bicep with the input below - note that I don't specify capacity on container level - then the container is being created via \Microsoft.DocumentDB\databaseAccounts\sqlDatabases\containers\main.bicep with explicit throughput of 400 (default value).

  params: {
    sqlDatabases: [
      {
        name: 'mydatabase'

        autoscaleSettingsMaxThroughput: 1000 

        containers: [
          {
            name: 'mycontainer'
            kind: 'Hash' // type of partition key
            paths: [ // partition keys
              '/id'
            ]
          }]
      }]
}

I think introduced recently and today still applicable in this piece of code

• If you don't specify autoscaleSettingsMaxThroughput it falls back to throughput
• throughput as null seems to lead to 400 as default value (?)
• Specifying either autoscaleSettingsMaxThroughput or throughput leads to container level explicit capacity what we don't want.

When I comment out [line 91 - 95 from containers/main.bicep[(https://github.com/Azure/ResourceModules/blob/0f05a13f030bd501c2eec80460d791b550cd04eb/modules/DocumentDB/databaseAccounts/sqlDatabases/containers/main.bicep#L90) and don't specify autoscaleSettingsMaxThroughput nor throughput, it works as intended. The Azure Portal (Cost management blade) then reports "Shared within mydatabase" as configured Throughput RU/s)

With the throughput defined with a default value of 400 and autoscaleSettingsMaxThroughput with a default value of -1 there is no proper possibility to verify whether explicit capacity needs to be configured on container level. For backwards capability and more explicit configuration of the shared capacity feature, maybe introduce a bool parameter useDatabaseLevelThroughput which default is false. Adjust the template that when useDatabaseLevelThroughput == true, both the options.throughput and options.autoscaleSettings are omitted from the resulting deployment.

I've tried to specify throughput: -1 (just like autoscaleSettingsMaxThroughput is supporting) but that didn't seem to work. Perhaps supporting that might be a solution if we want to be defensive in introducing new parameters

Code snippet

No response

Relevant log output

No response

[markdebruijne]

Workaround is that I now don't nest the configuration of the container within the module cosmosStackModule '../Microsoft.DocumentDB/databaseAccounts/main.bicep'module, but deploy additional depending resources afterwards, without specifying autoscaleSettingsMaxThroughput and throughput, works as intended

resource containerUserDataCarts 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers@2022-08-15' = {
  name: '${cosmosDatabaseAccountResourceName}/userdata/carts'
  dependsOn: [
    cosmosStackModule
  ]

  properties: {
    resource: {
      id: 'carts'
      partitionKey: {
        paths: [
          '/id'
        ]
        kind: 'Hash'
      }
    }
  }
}

[rahalan]

Needs to be investigated.

[microsoft-github-policy-service[bot]]

[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!

[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[AlexanderSehr]

Hey @bryansan-msft , I just migrated this issue over from CARML. Please take a look and triage if still relevant :)

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

• To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

• To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

• To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

• To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

• To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

[AlexanderSehr]

Hey @bryansan-msft, please take a moment to triage this issue if you can 💪