Streaming snapshots during a restore from a blockstore out to the MongoDB Agent cases the RTO (recovery time objective) to grow linearly with the compressed datasize in the largest shard/RS of the snapshot. The RTO of an Ops Manager restore could be very significantly improved by leveraging volume management infrastructure (such as from VMWare) to restore previously acquired snapshots as virtual filesystems (volumes).

MongoDB Operator can only deploy and manage MongoDB in a single Kubernetes cluster. However, for DR and global apps, it is important to deploy a single DataBase across multiple Kubernetes clusters to allow for DR or globally distributed apps.

Support all MongoDB configurations in Kubernetes CRD so that it is possible to deploy a fine-tuned cluster with Kubernetes resources

What is the problem that needs to be solved? SNMP traps for AUTOMATION_AGENT_DOWN, MONITORING_AGENT_DOWN, BACKUP_AGENT_DOWN alert types does not contain hostname information in .1.3.6.1.4.1.41138.1.1.1.4 (.iso.org.dod.internet.private.enterprises.mms.server.serverMIBObjects.mmsAlertObject.mmsAlertHostAndPort) OID.

Why is it a problem? (the pain) User is blocked to act quickly on the alert and identify the host where Ops Manager's Automation/Monitoring/Backup Agent is in DOWN state. Missing <HOSTNAME>:<PORT> information at .1.3.6.1.4.1.41138.1.1.1.4 SNMP OID does not allow user to map AUTOMATION_AGENT_DOWN, MONITORING_AGENT_DOWN, BACKUP_AGENT_DOWN alert types into a particular hostname.

Ops Manager currently allows the ability to rotate audit logs based on the threshold settings in the Update MongoDB Log Settings modal but audit.logs do not compress/delete as the mongodb.logs do from the same modal. We would like the ability to either toggle compression/deletion of audit.log in that modal or a separate modal. We think a separate modal would be better since audit.logs may be used for security forensics and require a longer retention period.

Many customers require that the MMS automation agent has a valid x509 for TLS communications with Ops Manager. With the Kubernetes Operator this is not currently possible so these customers cannot use the Operator to deploy MongoDB instances within their environments.

This feature would improve the security of communications between agents and the Ops Manager and meet the security requirements of many of our customers who cannot move to services like Atlas.

Allow configuration of backup settings in MongoDB Custom resource.
This includes management of backed up resources when updating, moving or deleting clusters

Ability to utilize API and/or UI to restore a snapshot downloaded from one Ops Manager deployment to a separate distinct Ops Manager deployment.

Some environments require separation of Production and Staging systems, including Ops Manager deployments. It is desirable to use Production data in some testing scenarios. Currently the data has to be loaded or restore manually.

For very large clusters, ideally backup resources should be assignable before the backup begins. For each shard and config server, assignment of the following would assist in scaling Ops Manager backups.

• Snapshot Store


• Oplog Store


• Backup Daemon (if using FCV <= 4.0)

Starting the backup could trigger an email to the Backup Administrator who could then assign these resources on the Admin page.

Ops Manager automation currently uses an mms-automation user for node management, but the password for that user is set once and stays forever unless it is updated via the Ops Manager API.

This feature would provide a mechanism that allows this password to be re-generated via the UI or an API call and have it automatically updated on the managed mongod instances as well.

Support arbiters with MongoDB Kubernetes Operator so that Replicasets should be deployed in PSA configuration.

Currently the option of "security.TransitionToAuth" is not available in Ops Manager as "transitionToAuth" is automatically added to each node in a rolling fashion by the Automation agent and then ultimately removed when authentication is finally turned on for all nodes.

Allowing this option through Ops Manager will enable the mongod to accept and create authenticated and non-authenticated connections to and from the connected clients. Thus the clients can use this feature to avoid downtime at their end while the connection settings are updated to use the appropriate user to connect to mongod.

Apply Project Maintenance Windows to Global Alerts

Make the existing Project-level maintenance windows also silence Global alerts associated with the Project.

We have many projects that share the Global Alerts and do not want to turn off all global alerts as we still need that alerting for the projects that are not being worked on.

In combination with the existing API for Project Maintenance Windows, this really allows full control.

A very common Enterprise HTTP Proxy configuration is to deny requests from local networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

In hybrid mode, the Backup Mode attempts to download the binaries from itself locally through the proxy. This brings to errors as the proxy is blocking the local traffic.

> 1.) What is the limiting factor of the Operator? Is it number of Pods, number of Custom Resources (e.g. MongoDB, MongoDBUser) or something else?

> 2.) What does the number of "Clusters" refer to? Does it differ for Standalone, ReplicaSet and ShardedCluster?

> 3.) How many instances of the "Clusters" in 2.) are supported per MongoDB Operator?

Is there any way to add this sort of data to our documentation?

Thanks

Integrity Check Jobs failures get emailed to the configured "mms.backup.alertsEmailAddr" address and logged in daemon.log. This information should also be available in Ops Manager UI so that the user can quickly check before trying any restoration.