[AVM Question/Feedback]: When will newer MongoDB server versions than 4.2 be supported for CosmosDB?

[aTTraX]

Check for previous/existing GitHub issues

• [x] I have checked for previous/existing GitHub issues

Description

Hi guys,

we use AVM for our infrastructure and want to update our CosmosDB to support the MongoDB server version 7.0, but it´s limited to max 4.2 as you can see here: AVM document-db/database-account#parameter-serverversion

Is there a reason why you only allow the following serverVersions: Allowed: [ '3.2' '3.6' '4.0' '4.2' ]

And is there an update for newer version planned?

Thanks in advance!

Markus

[FallenHoot]

It looks like you're aiming to use MongoDB Request Unit architecture (RUA) version 7, but currently, the databaseaccounts AVM module only supports MongoDB version 4.2 with the Microsoft.DocumentDB/databaseAccounts@2023-04-15 API. To enable MongoDB 7, you'll need to use the mongo-cluster AVM module otherwise known as MongoDB vCore, which defaults to the latest MongoDB version and doesn’t require specifying a version parameter. You can find out the difference between RUA and vCore .

If you're set on using the databaseaccounts module (RUA), an upgrade to the Microsoft.DocumentDB/databaseAccounts@2024-05-15 API is necessary to support MongoDB version 6 fully. No news on when version 7 will be supported for this. However, for MongoDB version 7, switching to the mongo-cluster module would be the most efficient approach since it’s already configured for this version.

The readme.md in those two modules needs to outline that one is for RUA and the other is for vCore to make sure it is less confusing.

Let me know if you need further guidance on this! Otherwise, this question can be closed.

[aTTraX]

Hey @FallenHoot, thank you very much for your fast reply. We will consider switching to vCore based.

[aTTraX]

Hi @FallenHoot, there is the possibility to manually set the RU-based MongoDB server version to MongoDB 7 via the portal in the CosmosDB-Features section. Does this manual update interfere with the future AVM update when version 7 is ready for RU via AVM? Do you know if there is a plan to release server version 7 in the next time?

[dmusic]

When trying over Azure Portal, it is possible to select version 7.0 also for RUA approach. Don't have instance provisioned now but it seems there is a valid version of Microsoft.DocumentDB/databaseAccounts supporting 7.0

[aTTraX]

When trying over Azure Portal, it is possible to select version 7.0 also for RUA approach. Don't have instance provisioned now but it seems there is a valid version of Microsoft.DocumentDB/databaseAccounts supporting 7.0

Exactly and it also seem to work because one of our developers upgraded via Portal to version 7, that´s why I ask if it has any influence on IaC based deployment in the future or not?

[dmusic]

When trying over Azure Portal, it is possible to select version 7.0 also for RUA approach. Don't have instance provisioned now but it seems there is a valid version of Microsoft.DocumentDB/databaseAccounts supporting 7.0

Exactly and it also seem to work because one of our developers upgraded via Portal to version 7, that´s why I ask if it has any influence on IaC based deployment in the future or not?

Well, it should be just an update within allowed values for MongoDB RU. I understand that vCore solution is the future one and best practice but why not supporting what is supported in official Azure Portal.

[FallenHoot]

I can only rely on the official documentation, which states that only version 6.0 is supported. Although RU (Aug 2024) and vCore (July 2024) models support version 7, the API (current as of May 2024) is limited to version 6. This applies across all deployment methods—AVM, Terraform, ARM, etc.—because the API does not permit deployment with version 7.

Here’s the error message you will encounter if you try to deploy the latest API with ServerVersion 7:

{
  "status": "Failed",
  "error": {
    "code": "BadRequest",
    "message": "ServerVersion is not allowed for this API type.\r\nActivityId: 9cb453bc-23db-4bf7-96f2-e92f5fe9630d, Microsoft.Azure.Documents.Common/2.14.0"
  }
}

The Azure Portal is using an API version - 2024-09-01-preview, but according to Bicep; The problem is that the resource type "Microsoft.DocumentDB/databaseAccounts@2024-09-01-preview" is not recognized. .

The best course of action is for me to check with the program manager for Cosmos DB for MongoDB about why the version published hasn't been updated. Nonetheless, we’ll need to create a PR for the AVM to reflect this. Something @Azure/avm-res-documentdb-databaseaccount-module-owners-bicep needs to look into.

[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.