Allow the possibility of performing a snapshot on-demand.

Usually the snapshot time ends too far away in time after configuration changes of the backup job (i.e: changing the block size). For testing purposes it would make sense to allow performing a snapshot on-demand to get it generated and proceed with further testing/tuning if required.

Why doesn't MongoDB provide a tool (integrated or standalone) to operate document migration across on-prem (sharded) clusters? Suggestion might be to officially support tools like "mongo push", which may cover situations of hardware changes, production servers migration, re-sharding.

The ability to Test Failover was added to Atlas https://docs.atlas.mongodb.com/tutorial/test-failover.

Please add this functionality to Ops Manager in order to facilitate failover testing. This is especially useful in multi-tenant Ops Manager setups.

Today, it is possible to install MongoDB software (mongoimport/export, mongodump/restore, mongo, bi connector) from Ops Manager via the automation agent.

Ideally, it will be possible to have the same experience for the new MongoDB Shell (mongosh), so that customers don't need to put in place a separate set of processes nd scripts to install it.

Atlas -> please make buffers, cached, and MEM shared available under system memory metrics on Atlas for end users so we can calculate the criteria for auto scaling .

Currently only Mongodb support can see these three metrics

Problem Statement,
What is the problem? MongoDB Agent (Automation Module) attempts to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509.

Why is this a problem? MongoDB Server process logs are flooded by unnecessary noise from such MongoDB Agent (Automation Module) failed auth attempts.

Example,
{"t":{"$date":"2021-05-10T11:08:02.115+0000"},"s":"I", "c":"ACCESS", "id":20249, "ctx":"conn115","msg":"Authentication failed","attr":{"mechanism":"SCRAM-SHA-1","principalName":"__system","authenticationDatabase":"local","client":"10.10.10.10:46765","result":"AuthenticationFailed: ###"}}

Proposal,
* Don't attempt to auth with __system (SCRAM) user when security.clusterAuthMode is set to x509 in MongoDB Server

SAML is available as an authentication mechanism and we're currently using it with keycloack (centralized identity provider).

It works well with Ops Manager but there seems to be no support whatsoever in Ops Manager 4.4 API to programmatically add / update / delete SAML groups on Organizations or Projects.

The official API documentation doesn't even recognize that SAML is available.

Mongo support has confirmed that and it's a target feature in their internal backlog.
This idea will hopefully speed up things.

If you are using local key file encryption and backing up your MongoDB deployment using Ops Manager, backups won't work correctly if you upgrade to MongoDB 4.2. The correct solution is to switch your encryption to KMIP. But if you try doing that, automation will get stuck!

It would be useful to have a "Test Alert" button for each configured alert in order to integrate and test alerts with third-party systems. Otherwise, it is difficult if not impossible to determine what the alert will look like until it is triggered.

Webhooks are available for Project and Global Alerts. However they are not available for System Alerts.

It would be ideal to be able to use Webhooks for all alerts.

For users running DBaaS MongoDB products powered by Ops Manager automation, it would be useful if the API provided a way to replicate the cluster import behavior where MongoDB users are automatically discovered. This would help in scenarios where an existing Ops Manager deployment fails, and hundreds of deployments need to be moved to a different Ops Manager without knowing what MongoDB credentials the end user of that deployment had created. Having this API would allow the DBaaS provider's own scripting/automation to orchestrate moving these deployments to a new Ops Manager stack with reduced downtime.

Ops Manager should allow Data Explorer to be configured with a Read Preferences and maxTimeMS options. Not having these options allows this tool to potentially trigger un-optimized queries to only hit primary nodes, which for high load production environments may cause un-expected problems.

Ops Manager can utilize S3 storage for the Oplog Store. It should be possible to define and configure an S3 Oplog Store from the Operator.

Add a filter for Global alert Configuration Page. It would be nice to have the ability to search for the specific alert to see if you have it configured and for which environments.

A filter similar to what is seen on the "Open Alert" view would be sufficient.

Since we are managing upwards of 50 deployments via Global Alerts this would be a useful feature.

Version 4.4 has support to monitor the App DB. Please add the ability to monitor the backup database as well.

Some parameters for Datadog are not configurable in Ops Manager. For example, "tagging". Adding this functionality would make using Datadog easier.

Configuring an S3 Snapshot Storage with IAM roles is only possible via Ops Manager UI or API.

It would be great to be able to do this configuration via the MongoDB Kubernetes Operator.