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

8 results found

  1. 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.

    44 votes
    3 comments  ·  Backup  ·  Admin →
    How important is this to you?
    started  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

    Hi All,


    We are developing a solution directly in Ops Manager that will support swapping their S3 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.


    We are targeting this feature to be included in a minor release of Ops Manager 8 by mid 2025 at this time.


    I will update this feedback item once launched.

  2. Support migrations to different snapshot stores

    Currently it is not possible to transition between snapshot store types.

    There are two options currently when transitioning to the new one.

    1. Terminate backups (deleting all previous snapshots)
    2. Create a new project and abandon the previous one to allow automated restores at a later time

    Both of these options are difficult to manage for large deployments. The first option requires you to store the snapshots elsewhere and disallows automated restores. The second option requires many operations and clutters the Ops Manager project list.

    Ideally we should be able to transition from any store location/type to any other location/type. One of…

    33 votes
    1 comment  ·  Ops Manager  ·  Admin →
    How important is this to you?
    started  ·  AdminEvin Roesle (Senior Product Manager, Cloud, MongoDB) responded

    Hi All,


    We are developing a solution directly in Ops Manager that will support swapping their S3 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.


    We are targeting this feature to be included in a minor release of Ops Manager 8 by mid 2025 at this time.


    I will update this feedback item once launched.

  3. arm64 support for Kubernetes Operator

    Arm64 processors are getting more and more popular. Would be really nice to be able to run MongoDB Kubernetes Operator on a Raspberry Pi cluster.

    Otherwise, meanwhile would be nice to get documentation updated on how to produce arm64 images to still make it possible without having full CI infrastructure support.

    17 votes
    7 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    How important is this to you?

  4. Authentication mode MONGODB-OIDC

    Support for authentication: MONGODB-OIDC

    security:
    authentication:
    enabled: true
    modes:
    - "MONGODB-OIDC"

    currently we get the following error wir kuberntes operator 1.26.0, OpsManager 7.0.7 and RS 7.0.11:
    Unsupported value: "MONGODB-OIDC"

    12 votes
    5 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    How important is this to you?

  5. Introduce Helm Chart for MongoDB, MongoDBUser and secrets

    Provide a helm chart that deploys MongoDB, MongoDBUser, secrets and all other resources needed.

    The goal is to simplify the deployment of a MongoDB instance and everything that comes with it down to a helm one-liner.

    9 votes
    4 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    How important is this to you?

  6. Binaries should be provided via Docker images

    To implement this in a Kubernetes native way for offline deployments, the binaries should be provided as Docker images and distributed through the Docker repositories that are already present in the k8s environment.

    Option 1 (intermediate): Allow Mount of Docker images in the MongoDBOpsManager resource for the path defined in automation.versions.directory. This would allow us to pre-package the binaries needed and bring up the OpsManager in a kubernetes native way. Everything else (e.g. agent downloading the tgz) would stay the same and still be the "OpsManger-way".

    Option 2 (long term): The MongoDB TGZ package is provided as Docker image by…

    5 votes
    started  ·  1 comment  ·  Ops Manager  ·  Admin →
    How important is this to you?

  7. Kubernetes Operator - Prefix Annotations and Labels

    Labels and annotations added to Kubernetes resources by the MongoDB Enterprise Operator should include a prefix designating that it was added by MongoDB. The lack of a prefix suggests the field and values are private to the user.

    For example, the MongoDB statefulset and service selector should use a label prefixed with a MongoDB domain.

    https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set

    4 votes
    0 comments  ·  Enterprise Kubernetes Operator  ·  Admin →
    How important is this to you?
    started  ·  AdminDan (Admin, MongoDB) responded

    We're gradually starting to change things to prefix most annotations and labels with mdb.


    It's a gradual thing but in progress.

  8. mongocli feature request: whitelist with timeout on current ip to allow temporary mongoshell access from temporary locations

    Please add a timeout parameter to the mongocli whitelist command.
    Presently, we have to login via web browser to enable temporary mongoshell access from temporary locations.

    2 votes
    started  ·  1 comment  ·  Other  ·  Admin →
    How important is this to you?
  • Don't see your idea?

Ops Tools

Categories

Feedback and Knowledge Base

(thinking…)