Currently a project is created with a set of default alerts. We need to customize these but we can only add new alerts via terraform. It would be helpful if there was a boolean flag in the mongodbatlas_project resource to disable default alert creation

We would like the option to have our Atlas backups automatically copied to a 2nd region to support our DR initiative. I realize we could create a live database node in a 2nd region, but that is more costly and complex. Having the backup sync to another region that we can restore off of in case the primary region fails would be simpler and more cost effective.

Is this something that is on your roadmap, and if so, when will it be released?

Thanks!

Allow the "SET GLOBAL mongodbmaxvarcharlength = n" to be permanent after a Mongosqld restart. Currently, the setting is ephmeral and must be set everytime the mongosqld daemon is restarted. Currently, our production environment mongosqld can restart without our knowledge at anytime. This results in the mongodbmaxvarharlength variable being reset to zero, which can lead to a production outage. Is there anyway this can be automated, maybe through database trigger?

The need to do two applies to completely configure the mongodbatlas_cloud_provider_access resource should have never seen the light of day. I would like to see an additional resource that could attach a role to a mongodbatlas_cloud_provider_access after it has been created. Then you could use the attributes in the mongodbatlas_cloud_provider_access resource to create the role, then attach the role to it using the access_role_attachment resource.

Right now, there's a "test failover" option, which shuts down the primary and forces an election. However, the option is only available if the cluster is in a healthy state.

If, for whatever reason, the cluster is unhealthy, it's impossible to manually restart the primary. It should be possible to force an election in an unhealthy state. Often, this is all that is required to get back into a healthy state (e.g. if the primary is in a CPU burning loop that was caused by an unexpected write pattern that has stopped.)

Please add support for the newly announced and already generally available AWS EBS feature. [1]

The top capability is: "The new gp3 volumes deliver a baseline performance of 3,000 IOPS and 125 MB/s at any volume size. Customers looking for higher performance can scale up to 16,000 IOPS and 1,000 MB/s for an additional fee." [2]

That basically means decoupling storage performance from storage size.
It would eliminate all our IOPS pain as 3000k is more than enough for our usecase. Currently, we are slightly overprovisioning storage size in order to guarantee minimal IOPS performance.

[1] https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-new-amazon-ebs-general-purpose-volumes-gp3/
[2] https://aws.amazon.com/ebs/general-purpose/

Please release a dark mode MongoDB Atlas interface. Thank you.

Currently there is only a community supported Prometheus integration (exporter) available which polls db.serverStatus() and doesn't include as much metrics as the Atlas UI/API provides. A similar integration as with New Relic and Datadog would help many customers that are using Prometheus and Grafana for monitoring.

To help catch heavy disk workloads before they become problematic, it would be great to have alerts on:
- disk IOPS percentage utilization for disks without burstable IOPS
- burst credit utilization for disks with burstable IOPS
- CPU IOWAIT %

Achieve feature parity with AWS IAM cluster authentication support.

Add a button/toggle to Hide and Unhide an Index from the Data Explorer/Indexes display for a 4.4+ deployment.

Since we want to automate the user (de)provisioning for organizations and projects, we would like to see the following API enhancements:

Please enhance the Mongo Atlas API for the following functionalities:
- invite (existing mongo) user to organization (currently not possible)
- remove user from organization
- get invitation status from user
- cancel invitation for user

Thank you

Currently there is no way of managing an online archive besides nuking the entire collection. This means that the collection can only grow, so costs will continue to climb.

The TTL index can already be used to automatically delete documents from your database. If this could be expanded to also delete files which have been archived, there is an easy and built-in way of maintaining an archive in size.

Mongomirror allows you to migrate particular databases or collections using the --includeDB and --includeNamespace parameters:

https://docs.atlas.mongodb.com/reference/mongomirror/#cmdoption-includedb
https://docs.atlas.mongodb.com/reference/mongomirror/#cmdoption-includenamespace

It would be helpful if Live Migrate allowed for use of these options as well to migrate subsets of data, instead of only migrating an entire cluster.

The speed at which usable monitoring metrics data (1m, 5m) is purged and reduced to 1hr is way too quick.

After 1hr, the ability to analyze these metrics that are crucial to investigating a performance issue were lost and hindered the root cause analysis.

I would suggest that 1m or at least 5m resolution metrics be retained for at least a week before being purged.

What is the problem that needs to be solved? As a user (MongoDB Driver) you'd like to check revocation status of X.509 certificate via TLS Certificate Status Request extension (also known as OCSP stapling) instead of doing outgoing HTTP connection to OCSP endpoint from a user (MongoDB Driver) side.

Why is it a problem? (the pain) [MongoDB Server v. 4.4.X introduces OCSP stapling functionality](https://docs.mongodb.com/manual/release-notes/4.4/index.html#ocsp), however OCSP stapling is not enabled on Atlas Clusters with MongoDB Server v. 4.4.X.