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.

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.

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.

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!

In order to separate replication, client and administrative traffic, servers may have multiple network interfaces using different IP and hostname aliases associated with them.

According to the requirements described on https://docs.opsmanager.mongodb.com/current/tutorial/provisioning-prep/#server-networking-access Automation currently can use only the server hostname defined as hostname -f and cannot use any of the other aliases matching to other IP addresses for the other machine host aliases.

Please add some way to customize which host alias Automation should use as a configuration parameter for the Agent.

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.

In Ops Manager ,Whenever we do changes in the configuration the deployed mongodb instnaces ,GUI prompt for Review & Deploy ,If we have a provision for schduling the deployment in later time would fullfil the real Automation.

• Do the changes at convenient time


• Do deploy thru a schedulers

Starting with MongoDB 4.2 we are able to rotate the internal authentication keyfiles in a rolling fashion with the procedure described here:
https://docs.mongodb.com/manual/tutorial/rotate-key-sharded-cluster/

Currently when you import for automation a cluster that is using a different keyfile than the one in the automation config a bouncerestart is triggered. We can avoid it by doing a rolling rotation of the keyfile.

The old keyfile should be kept and the new one appended to it in a rolling fashion. We may have already this implemented for the "Rotate keyfile" feature present in the Security tab page.

Currently, Ops Manager does not support stop/start/restart BI Connector that is managed by Ops Manager Automation. There is only a Terminate option available.

In Windows, managed MongoDB processes are installed as services. In Linux, they are not. It would be great if managed processes were installed as services so that system administrators would have better control over startup and shutdown behavior, among other things.

When reviewing changes in automation, warn if deploying changes will require a rolling restart.

As an example, look at the documentation for server parameters: https://docs.mongodb.com/manual/reference/parameters/

Many parameters include the description "You can only set THIS during start-up", but a warning that setting this parameter implies restarting MongoDB is missing from Ops Manager (or Cloud Manager).

When reviewing changes in automation, warn if deploying changes will require a rolling restart.

As an example, look at [the documentation for server parameters](https://docs.mongodb.com/manual/reference/parameters/). Many parameters include the description "You can only set THIS during start-up", but the the warning that setting this parameter necessitates a restart is missing from Ops Manager (or Cloud Manager).