/mms/mongodb-releases/ is continually updated with the most current minor release of each major version which can fill the partition.
This request is for "Only download to /mms/mongodb-releases/ those versions actually in use in a deployment"
eg if I am only using 4.2.20 in my actual deployments only download the most recent 4.2.x and not 3.6.x
of course if I do decide to deploy a 3.6.x deployment this FR would need to automatically be bypassed and download my 3.6.x and the most recent 3.6.x.
This request is similar to but not the same as another Feature Request:
[Do not download EOL releases](https://feedback.mongodb.com/forums/924355-ops-tools/suggestions/41942782-do-not-download-eol-releases)

Currently, when you use OPS Manager to shard a collection, it automatically creates a foreground index that exactly matches the sharding key, when such index doesn't exist. When the sharding key column(s) is(are)already prefixing an existing index, it's not sufficent.
This is dangerous in Live environments because the whole database is blocked for a long time (sharded collections are usually big collections).
So, several features could exist :
- before continuing with sharding, OPS Manager warns that it needs to create this foreground index first. You can stop if you don't agree (and create this index by yourself first).
- OPS Manager creates instead a background index or creates this index with the rolling manner.
- OPS Manager is able to use one exiting indexes that contains the sharding key as a prefix of this index, no need to create a new one.

New versions of Ops Manager have the ability to monitor the ApplicationDB in a organisation/project with the "backing database" server type (https://docs.opsmanager.mongodb.com/master/reference/config/ui-settings/#mongodb-usage).

It is common to co-host the blockstore/oplogstore database on the same servers as the ApplicationDB and I would like to deploy these using OpsManager automation but there is a problem because:
* you cannot deploy new clusters in projects with the "backing database" server type
* an agent is tied to a single Ops Manager project

I have two options at the moment:
1. Install a secondary agent on the servers to allow me to deploy the blockstore/oplogstore database in a different project (this is possible but, AFAIK, not technically supported)
2. Create a new project and use this to monitor the AppDB and deploy the blockstore/oplogstore database - the downside of this is that it is possible to enable backups for the backup database (which will cause all kinds of problems) and enable automation for the AppDB (which will also cause problems).

Ideally, I would like to have a project which:
1. monitors the AppDB (but doesn't allow me to enable automation for it)
2. allows me to deploy blockstore/oplogstore databases (but prevents me from enabling backups for these deployments)

Extra credit if there is a big friendly button which creates the blockstore/oplogstore and automatically configures it as a blockstore/oplogstore in the Ops Manager backup configuration.

Sometimes customer want to clean up the System Overview page and/or the application db from because:
- They dismissed one or more Ops Manager server running Application servers or backup daemon components
- Their hostnames / domains have changed over the time
- Their hostnames have changed from lowercase to capital letters or vice versa because upgrading Ops Manager brought a JVM providing different values for getHostname() (this happens often in Windows environment).

It would be nice to have a button or at least an API call similar to the project reset duplicates that forces Ops Manager to refresh the internal host mappings and the appstate.

We run routine, recurring aggregation pipelines (essentially, summing up the values of different categories of transactions) on a 5-minute interval. These aggregation pipelines scan for all objects that match a certain type, then sum the cumulative value of certain values of those objects based on category. This means that we regularly have queries that scan >500,000 objects and consolidate them down to ~12 or so objects that are returned.

In this specific case, I'm alright with the scan/return ratio being very high, and I don't want to be spammed with alerts every five minutes. However, I don't want to disable this alarm for all queries, just these recurring ones that I expect to have a poor ratio.

This is strictly cosmetic, but in Ops Mgr Deployment->Processes->deployment, it would be nice to be able to drag-and-drop the order of the servers. I believe it shows them in the order they were added to the replica set, the same as rs.status() or rs.config() would show, but for our deployments, we typically have 2 "main" systems, and then a third "DR" system. It would be great if I could always have our main systems as the first 2 systems, and then our "DR" system last, regardless of how they were added to the replica set. The order they were added to the replica set is unimportant to me.