Hi
Presently, we can only create permanent database users via Terraform Modules. The creation of temporary DB users is only allowed through the UI or by consuming MongoDb Atlas's APIs. In addition, the "deleteAfterDate" property is only applicable for a temporary user already existent. The point is to avoid using "null_resource" and "local-exec" in our Terraform Modules.

In the old interface we can truncate collections without using additional software, just using WEB GUI to keep small database size.
It would be nice to have the ability to delete older documents. This option is usable for IOT or medical implementations (Nightscout).

I'm trying to get logs from MongoDB Atlas to Splunk, and there's currently no native interface to do it, so instead of streaming to Splunk directly, I'm having to execute https calls in intervals, unzip them and then ship them to Splunk. Many products have interfaces to stream to Splunk directly, and it would certainly be handy in this situation.

Please include the human-friendly cluster/host names in Monitoring Alert Notifications (e.g. email, PagerDuty, etc) in addition to, or instead of, the less clear internal cluster/hostnames (i.e. atlas-abcdef-shard-0).

Achieve feature parity with AWS IAM cluster authentication support.

Provide some callback method (webhook URL, push notification, etc) that an API call can use to indicate it's done. That way the user doesn't have to sit and poll endlessly.

Some examples of where this would help:

• After creating a restore job, waiting for the snapshot download URL to be ready.


• After modifying the automationConfig, waiting for all agents to report that they're in goal state.

It would be nice to have the killOp() action exposed when creating a custom role in Atlas.

I also think it would make sense to grant this action to the atlasAdmin role, but at a minimum I feel that Project Owners should be able to create a custom role that is allowed to kill ops that were initiated by other database users.

We would like to be able to use Terraform to configure LDAP authentication/authorization on projects.

The functionality is available via the API:
https://docs.atlas.mongodb.com/reference/api/ldaps-configuration/

However, go-client-mongodb-atlas does not have these endpoints implemented, so that would need to be done before this functionality is included in the provider.

The Legacy Backups have a feature to allow connecting (tunnelling) to a snapshot to query it. This allows querying a database snapshot which is great for quickly inspecting data in the past for troubleshooting. This would be handy to have for the Cloud Backups. With Cloud Backups instead I now have to download a snapshot, load it temporarily on a cluster and remove it when done.

Add support to send cluster metrics to Elastic. Elastic has recently been putting a lot of work into their APM and logging solution, this is now a viable alternative to NewRelic and Datadog and is gaining traction. It would be great if Atlas supported sending metrics to Elastic. Please see below for references

https://www.elastic.co/apm
https://www.elastic.co/siem

The use case for this is the same as NewRelic or Datadog. I wish to monitor my Atlas clusters from inside Elastic, create dashboards and set up alerting

Within Atlas today, we have a number of channel options to send alerts (Ex. OpsGenie, Slack, VictorOps).

I would like to see a hook integration provided by Atlas so any tool can recieve alerts from their cluster. Ex. I can recieve my cluster alert in Microsoft Teams.

3rd party hooks can increase the stickiness of Atlas and improve freedoms for teams and their existing toolsets.

It could be incredibly helpful if we had a way to set a schedule to pause any given cluster as well as a schedule to un-pause it. This would help with cost savings and would allow to shutdown development clusters on weekends, after hours and holidays.

It would be great if Atlas provided support for hidden, priority 0 delayed replicas. For workloads that do not need real time data or situations where data recovery is needed, a delayed replica would be the fastest way to mitigate both of those scenarios.

We have a need to rename our databases as we sync them over to Atlas. However, mongomirror doesn't support that. So that leaves us with mongodump and mongorestore but our databases are large enough that we can't take the outage window necessary to go down that path. When will mongomirror support renaming databases during the import process?

It would be great if we could organize the projects and not have them all at the same level of organization.
We could use this hierarchy to put rights, consult costs ...
A bit like the idea of Azure's management group or GCP's "Folder".

When monitoring disk IOPS, it isn't immediately clear when we are limited on IOPS. Having a red limit line on the IOPS chart on the metrics tab would help here.