Skip to content

Ops Tools

← MongoDB Feedback Engine

How can we improve the Operational Tooling MongoDB provides?

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

41 results found

  1. Add spec.externalAccess.externalDomain to running deployments

    The follow option:

    https://www.mongodb.com/docs/kubernetes-operator/master/reference/k8s-operator-specification/#spec.externalAccess.externalDomain

    • spec.externalAccess.externalDomain

    Is tremendously useful as we would no longer have to worry about terminating TLS connections through a proxy and then re-establishing a TLS connection for internal communication due to security reasons.

    This would remove a point of failure for self-hosted Kubernetes environments and safe resources.

    However, you cannot do this for existing replica sets:

    WARNING

    Specifying this field changes how Ops Manager registers mongod processes. You can specify this field only for new replica set deployments starting in Kubernetes Operator version 1.19. You can’t change the value of this field or any processes[n].hostname fields in…

    2 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    completed  ·  AdminDan (Admin, MongoDB) responded

    We've just tested this for existing deployments and confirmed that this does in fact work fine for existing replica sets. 


    This was an incorrect inference made while documenting this feature and we've raised a ticket to have our docs amended.

  2. Custom Pod Annotations

    This is regarding usage of service mesh / policy agent automations for stateful sets.

    1 vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    1 comment  ·  Enterprise Kubernetes Operator  ·  Admin →
    completed  ·  AdminDan (Admin, MongoDB) responded

    This is already possible actually! Though it's definitely an area where we need to improve our docs.


    In any valid working MongoDBCommunity deployment you'd need to specify:

    spec:
     statefulSet:
       spec:
         template:
           metadata:
             annotations:
               example.com/annotation-1: "value-1"
               example.com/annotation-2: "value-2"


    And obviously alter the annotations according to your needs!

  3. mongodb-atlas-kubernetes operator need to adjust instanceSize/disk for autoscaled cluster base on instanceSize range

    Scenario:

    Assumptions:
    autoscaling = true
    current instanceSize = M40
    minInstanceSize = M30
    maxInstanceSize = M70

    If we want to increase the minInstanceSize from M40 to M50 operator will return an error because our current instance size is less than M50, so we need to go to UI and increase the current instance size to M50(at least), and then apply the change to Kubernetes object (atlasdeployment).

    We expect that if the current instanceSize is not in the range, the operator automatically increases the instanceSize to minInstanceSize to remove the extra step.

    We expect the same logic for increasing/decreasing - minInstance/maxInstance and…

    7 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    1 comment  ·  Other  ·  Admin →
    completed  ·  AdminDan (Admin, MongoDB) responded

    Resolved in version 1.4 of the Atlas Operator


    It now allows the user to update the autoscaling config (min and max) to outside of current instance size and atlas will update the instance to the closest boundary. So, for example, with a current instance size on Atlas of M10, and a min and max of M10 and M30, the min and max could be changed to M30 and M80, and the instance size would now be auto-scaled up to M30 (as the nearest boundary to the old instance size). Side note: If the instance size in the config is not changed and is left at (for example M10), then you will get a warning in the logs that the spec contains an instance size outside of the current min and max. But that won't block the change or the auto-scaling.


    Similarly, you can also now change the fixed instance size in…

  4. Allow creation of Custom Roles in AtlasDeployment

    I'm missing a feature to create custom roles from deployment level for Atlas operator (as already possible in community operator: https://github.com/mongodb/mongodb-kubernetes-operator/blob/b232901f5c6e4f9c1ab04bc9725458ca70a19930/config/crd/bases/mongodbcommunity.mongodb.com_mongodbcommunity.yaml#L173-L258)

    1 vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    1 comment  ·  Enterprise Kubernetes Operator  ·  Admin →

  5. On demand snapshots in Ops Manager

    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.

    82 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    8 comments  ·  Backup  ·  Admin →

  6. MongoDB Agent (Automation Module): don't attempt to auth with `__system` (SCRAM) user when `security.clusterAuthMode` is set to `x509`

    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

    6 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    1 comment  ·  Automation  ·  Admin →

  7. Kubernetes Operator - Enable S3 Oplog store

    Currently, only Replica Sets are the only to deploy an Oplog Store with the Kubernetes Operator.
    This causes issues related to sizing for Ops Manager deployments managing a big number of projects.
    Enabling S3 Oplog Store would help a lot.

    1 vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    1 comment  ·  Enterprise Kubernetes Operator  ·  Admin →

  8. Allow S3 Oplog Store to be defined and configured using the Operator.

    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.

    4 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Admin →

  9. k8s operator - Support different different size shard configuration

    We would like to implement the Hot-cold shard strategy to move the cold data to a shard which has more disk usage and less compute power and not frequently used and Hot data in a shard with more compute power. This strategy is described here: https://docs.mongodb.com/manual/tutorial/sharding-tiered-hardware-for-varying-slas/

    Currently the enterprise operator does not support different size shards, this request is to allow operator to create different size shards.

    1 vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    completed  ·  AdminDan (Admin, MongoDB) responded

    We have recently released the ability to support different sized shards and that enables the scenario described in this idea.


    This is supported in 1.19.1 of the Operator, the release notes can be found here and the relevant section is as follows:

    • Allows you to configure podSpec per shard in a MongoDB sharded cluster by specifying an array of podSpecs under the spec.shardSpecificPodSpec setting for each shard.

  10. Fine-tune RBAC rules for mongodb.com resources

    Right now, the default RBAC rules for the mongodb-enterprise-operator role/clusterrole are:

    apiGroups:
  - mongodb.com
resources:
  - mongodb
  - mongodb/finalizers
  - mongodb/status
  - mongodbusers
  - mongodbusers/status
  - opsmanagers
  - opsmanagers/finalizers
  - opsmanagers/status
verbs:
  - "*"

    Available at https://github.com/mongodb/mongodb-enterprise-kubernetes/blob/b4c0a9b167f21114dc276cb163a1b207ae2f9359/helm_chart/templates/operator-roles.yaml#L90

    This doesn't doesn't work well with privilege escalation because it won't work for service accounts that individually mention the allowed verbs.
    For example, my service account has permissions for everything (create, delete, deletecollection, get, list, patch, update, watch), but it fails with (...) is attempting to grant RBAC permissions not currently held because they are not equal to "*".

    The proposed change is…

    2 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Admin →

  11. Allow Ops Manager users to move/migrate backup job snapshots from one S3 bucket to a different S3 bucket

    Ops Manager users with S3 blockstores may need to move snapshots and backup jobs to a new S3 bucket. For MongoDB blockstores, this is accomplished using a groom.

    Move Blocks to a Different Blockstore
    https://docs.opsmanager.mongodb.com/current/core/administration-interface/#groom-priority-page

    This feature request is to provide the same feature to groom backup snapshots/jobs to a new bucket for S3 blockstores.

    45 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    3 comments  ·  Backup  ·  Admin →
    completed  ·  Asif responded

    Hi All,


    We have developed a solution directly in Ops Manager that will support transitioning your S3-compatible snapshot storage without terminating the backup. Ops Manager will allow you to update the S3 snapshot store ID in the backup job document and the next scheduled snapshot will be a full snapshot in the new S3 snapshot store after the update. This is specifically for S3 stores only at this time.


    This feature is included in the Ops Manager 8.0.6 release that came out on April 3rd, 2025. 


    Information about this feature can be found in these documents:


    Release Notes: https://www.mongodb.com/docs/ops-manager/current/release-notes/application/


    UI Configuration: https://www.mongodb.com/docs/ops-manager/current/admin/backup/jobs-page/#std-label-transition-s3


    API Information: https://www.mongodb.com/docs/ops-manager/current/reference/api/backup/update-backup-config/



  12. Deploy MongoDB across different Kubernetes clusters

    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.

    44 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    9 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    completed  ·  AdminDan (Admin, MongoDB) responded

    MongoDB Enterprise Operator now support multi-Kubernetes-cluster replica set deployments.


    Find out more


    Multi-Kubernetes-cluster Ops Manager support is in progress right now with a likely delivery date towards the end of this year (2023). Sharding support (across multiple Kubernetes clusters) will follow.


    If you're an Enterprise Advanced customer and interested in this, please feel free to reach out to me at dan.mckean@mongodb.com.

  13. Ability to to turn on audit log compression/deletion

    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.

    28 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    6 comments  ·  Automation  ·  Admin →
    completed  ·  AdminMelissa (Lead Product Manager, MongoDB) responded

    We are pleased to announce that Cloud Manager and Ops Manger (5.0.8) now have the ability to set up a different configuration for rotation of MongoDB Log and MongoDB Audit Log Files.  This does depend on a feature available in MongoDB Enterprise Server 5.0 and up.  


    Documentation:

    OM: https://docs.opsmanager.mongodb.com/current/tutorial/view-logs/index.html#configure-log-rotation

    CM: https://docs.cloudmanager.mongodb.com/tutorial/view-logs/#configure-log-rotation

  14. Automatic labeling of pods by replicaset role (primary/secondary)

    Hi, I think it would be great if the Operator could watch and automatically mark individual pods of statefulset with some label indicating whether the node is primary or secondary to be able to route service just to the primary instance (or load balance secondary instances for read-only access on one IP).

    Currently I use a script that periodically checks roles and adds label "mongodb-replicaset-role": "primary" or "secondary" and a service that uses this as a selector.
    EDIT: (I'm thinking about writing own operator for this instead of script; maybe it's the best way?)

    Motivation: Linode (and possibly others') kubernetes…

    1 vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Admin →

  15. Do not delete backups of deleted deployments

    Backups normaly protect from accidental deletion of a database. In a devOps environment it can happen that a MDB resource gets deleted by a Kubernetes deployment. At the moment, Ops Manager then deactivates the backup and deletes all snapshots. We would like to have the snapshots stored as long as their retention limit tells or at least until the project itself is deleted in Ops Manager.

    So that, if a developer detects the mistake and re-deploys the MDB resource(s), someone or even himself can restore the database(s) from the backups.

    7 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    3 comments  ·  Ops Manager  ·  Admin →
    completed  ·  Andrey responded

    We do not delete Ops Manager project when Backup is present.
    This has been addressed

  16. Give MongoDB operator the ability to set compute or memory container requirements

    1 vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    1 comment  ·  Enterprise Kubernetes Operator  ·  Admin →

  17. Pin image tags in Enterprise Kubernetes Operator values file

    Should be able to pin tags for images like mongodb-enterprise-appdb in https://github.com/mongodb/mongodb-enterprise-kubernetes/blob/master/helm_chart/values.yaml

    Currently, we are forced to use the latest tag, which has caused issues and broke disaster recovery for our project.

    If we would have been able to use an older tag of the image, we could have recovered fast. since we were forced to use the latest tag, it took several days to recover. This does not seem acceptable for an enterprise software.

    1 vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Admin →

  18. Define current limits of Kubernetes Operator

    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

    9 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    2 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    completed  ·  AdminDan (Admin, MongoDB) responded

    Current scale recommendations are 20-50 deployments (ReplicaSet/ShardedCluster/Standalone). 


    While the Operator can handle hundreds, the limiting factor is API calls to Ops Manager/Cloud Manager. Updating one deployment at a time is fine, the issue arrises when making concurrent changes to many deployments simultaneously, where reconciliation will be slow for those later in the queue - for example during a DR scenario.


    We have work planned for later in 2023 to start removing Ops Manager as a prerequisite for many of the basic operations, and we expect that to greatly improve these limits.

  19. Support Namespace Filter for Ops Mgr Backups with MongoDB FCV 4.2

    11 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    2 comments  ·  Ops Manager  ·  Admin →

  20. Support Any MongoDB configuration option in MongoDB Custom Resource

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

    11 votes

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    completed  ·  1 comment  ·  Enterprise Kubernetes Operator  ·  Admin →
← Previous 1 3
  • Don't see your idea?

Ops Tools

Categories

Feedback and Knowledge Base

(thinking…)