448 results found

1. add clusterId to json output of "cluster list", "cluster describe" commands

   currently there is no straightforward way to get clusterId using mongocli. we can get clusterId if we use text format with "cluster list", but not with json.

   and with json format we have to use "process list" command, filter out only one process amongst multiple within cluster and filter out clusterId.

   it would be useful to add clusterId field into json when we get cluster description from list/describe commands also.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  MongoDB CLI for Cloud Manager and Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. add text option to --output modifier

   currently there is no way to format output of command in text format. the only option is to set this format as default in config file and not use --output modifier in specific command. if you rare use text output, you will have to insert --output json in every other commands.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  MongoDB CLI for Cloud Manager and Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Allow Enterprise Kubernetes Operator to downgrade FCV
   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Ops Manager API should be authenticated via Certificate

   Ops Manager API uses HTTP Digest Authentication, this method requires a username and a password which are hashed and provided in the form of registered Ops Manager account, and the password which is a Public API Key associated with that account.

   But as part of security feature we should be allowed to use Authentication based on SSL certificates as we are using for Client connection, This will help to secure the self automation process if we are developing any internally.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. When changing snapshot retention, prompt user to apply new policy to existing snapshots

   Currently when you change the snapshot schedule, the changes only apply to NEW snapshots.

   Please allow the user the option to apply the new policy automatically to all existing snapshots. Or at the very least, notify them of them of snapshots that exist which do not meet the current policy!

   ---

   Let me provide an example of the problem. If you have a retention policy of 10 days and on DAY1 you change it to 30 days, your retention will look like this:

   DAY1 - 10 snapshots
   DAY2 - 10 snapshots
   ...
   DAY10 - 10 snapshots
   DAY11 - 11 snapshots
   DAY12 - 12 snapshots
   ...
   DAY30 - 30 snapshots

   It takes 30 days to build up to the desired number of retained snapshots, even though you already had 10 perfectly good snapshots you could have kept if their expiration was bumped to creationTime+30d.

   ---

   This problem exists in other direction, too. Let's say you reduce your retention from 30d to 10d, it will look like this:

   DAY1 - 30 snapshots
   DAY2 - 29 snapshots
   ...
   DAY15 - 25 snapshots (15 of them are 15+ days old!)
   DAY16 - 24 snapshots
   ...
   DAY20 - 20 snapshots (10 are 20+ days old!)
   ...
   DAY30 - 10 snapshots

   At DAY20 you have snapshots from 1-10 days and 20-30 days ago, with a wonky gap between 20-30 days.

   Currently when you change the snapshot schedule, the changes only apply to NEW snapshots.

   Please allow the user the option to apply the new policy automatically to all existing snapshots. Or at the very least, notify them of them of snapshots that exist which do not meet the current policy!

   ---

   Let me provide an example of the problem. If you have a retention policy of 10 days and on DAY1 you change it to 30 days, your retention will look like this:

   DAY1 - 10 snapshots
   DAY2 - 10 snapshots
   ...
   DAY10 - 10 snapshots
   DAY11 - 11 snapshots
   DAY12… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Lock enableLocalConfigurationServer setting on OPS Manager side

   To harden security for mongodb deployment managed by OPS Manager, we can use setting enableLocalConfigurationServer = true so automation-mongod.conf won't have any passwords for ssl certs and agent will retrieve them from OPS Manager.

   to disable this feature and to read all passwords for ssl certs (and hence get access to mongodb data) it's enough to comment out this parameter an restart automation service (or wait until host will be restarted).

   Linux root user can modify any file on mongodb host including this file and can restart any services, so it's impossible to protect getting all passwords and mongod.conf from root user only using Linux functionality.

   But it's possible to add feature in OPS Manager to "lock automation agent setting for enableLocalConfigurationServer" on OPS Manager side.

   Even if root comments out/disables this setting, automation agent will request full config file from OPS Manager and OPS Manager will check on its side if it's allowed to send full config back to agent.

   i.e. only MongoDB DBA who manages deployment from OPS Manager controls if full config with all password should be sent to host and Linux root user won't be able on their own retrieve passwords.

   To harden security for mongodb deployment managed by OPS Manager, we can use setting enableLocalConfigurationServer = true so automation-mongod.conf won't have any passwords for ssl certs and agent will retrieve them from OPS Manager.

   to disable this feature and to read all passwords for ssl certs (and hence get access to mongodb data) it's enough to comment out this parameter an restart automation service (or wait until host will be restarted).

   Linux root user can modify any file on mongodb host including this file and can restart any services, so it's impossible to protect getting all passwords and mongod.conf from… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. The Ops Manager UI provide an option to trigger election (stepDown)

   Have the option to perform primary stepDown from Ops Manager UI to trigger election

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Authentication support for OpenID connect (OIDC)

   I would like to connect to MongoDB as part of a Terraform IaC project from bitbucket pipelines. Currently this is possible only through API keys.

   It would be great if there was support for OIDC as it provides rotated keys and solid support of various pipelines (GitHub actions, Bitbucket pipelines, ...). Also with OIDC the client is not exposed to any credentials, so this would allow for a "zero-trust" approach when it comes to IaC (Infrastructure as Code).

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Automation  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. I found what I believe to be an error in the following document

   I found what I believe to be an error in the following document.
   https://www.mongodb.com/docs/ops-manager/current/tutorial/install-simple-test-deployment/

   In the section "5. Create the Ops Manager Application Database directory," it instructs to execute the following command
   sudo chown -R mongod:mongod /data

   In my environment, the mongod user does not exist and I get an error, but looking at the passwd file, the mongodb user and mongodb group seem to exist. The version is 11.7.

   I think the correct command is as follows
   sudo chown -R mongodb:mongodb /data

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Operating System distribution and version of a host in OPS Manager API

    Hi,
    would be useful having the operating system distribution and version of a host for our automation scripts.
    This info is not available in any OPS Manager API request, as the case 01119828.
    My suggestion is add this info at "Get Host by ID" https://www.mongodb.com/docs/ops-manager/current/reference/api/hosts/get-one-host-by-id/
    Best regards,
    Danilo

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Ability to mark a deployment as an INELIGIBLE restore target

    Restoring to a cluster is one of the few destructive actions that Ops Manager takes and it's terrifying to see our main production cluster listed as a possible restore target!

    I would love to be able to toggle a setting on this cluster to indicate that it is NOT available as a restore target.

    This could be similar to the AWS "DisableApiTermination" feature that prevents instance termination.
    https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Multi Region S3 BlockStore

    On an S3 Blockstore, right now we are able to stick to only one region backup because S3 do not support versioning & Replication. For an high availability systems a backup also needs to be in multiple regions.

    If we could add the following that will be good.
    1. Configure Multiple backups in a project because S3 snapshot store can be only used in one region.

    5 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. Ops Manager Load Balancer

    In the same way we can connect to a replica set via a connection string containing the 3 hostnames of the members (in a 3 member replica set) which indicates some load balancing built in, it would be good to allow automation agent's mmsBaseUrl parameter to accept 3 Ops Manager web app hostnames if Ops Manager was running in 3 nodes on top of a 3 member replica set OM Application DB. With this, if one of the 3 Ops Manager web apps fails, the agent's connection to OM will be uninterrupted. Currently we will have to configure our own load balancer, or manually update the agent's mmsBaseUrl if the current OM fails both of which are tedious setups.

    In the same way we can connect to a replica set via a connection string containing the 3 hostnames of the members (in a 3 member replica set) which indicates some load balancing built in, it would be good to allow automation agent's mmsBaseUrl parameter to accept 3 Ops Manager web app hostnames if Ops Manager was running in 3 nodes on top of a 3 member replica set OM Application DB. With this, if one of the 3 Ops Manager web apps fails, the agent's connection to OM will be uninterrupted. Currently we will have to configure our own… more

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Add recommended ulimit settings to the systemctl service definition

    The Ops Manager documentation recommends higher than default ulimit settings, so why not include these in the systemctl service definition?

    https://www.mongodb.com/docs/ops-manager/current/core/requirements/index.html#ulimits-requirements-for-application

    2 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Export Cloud Backup to AWS S3 as CPS

    Currently, the Atlas provides possibility to configure an automated export cloud backups to an AWS S3. It uploads the contents of your database to S3 as gzip files with documents in extended JSON format within. It is possible to restore from these files using mongoimport tool.

    However, for some our use cases we would like to have backups exported to our AWS S3 as CPS (cloud provider snapshots) - actually a snapshot of the database directory at the filesystem level - in order to be able to restore very fast (the import via mongoimport and re-building of indexes can take considerable time when restoring from JSON format).

    We know that there is an option to download a CPS snapshot manually or via API (https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Cloud-Backup-Restore-Jobs/operation/restoreOneSnapshotOfOneCluster), but it requires either manual action or some scripting to periodically invoke administration API.
    It would be great to complement the automated export to AWS S3 functionality and add possibility of automated exports as CPS.

    Currently, the Atlas provides possibility to configure an automated export cloud backups to an AWS S3. It uploads the contents of your database to S3 as gzip files with documents in extended JSON format within. It is possible to restore from these files using mongoimport tool.

    However, for some our use cases we would like to have backups exported to our AWS S3 as CPS (cloud provider snapshots) - actually a snapshot of the database directory at the filesystem level - in order to be able to restore very fast (the import via mongoimport and re-building of indexes can take… more

    3 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Deploy Changes without restarting mongod/mongos instance immediately.

    Whenever we want to make changes, eg. set a new parameter or add new parameter in configuration (advance configuration options), after we save changes, review and deploy, automation immediately starts applying that change and does a rolling restart.
    We need flexibility in restart, means one should have an option to perform immediate rolling restart or defer it to later time. We may apply multiple changes at different times and set one preferred window to restart instance instead of doing multiple restarts.

    15 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Restore indexes using mongoimport - metadata.json

    When importing an archive from s3 we are given compressed gz files for the JSON data and a metadata.json file which has index info, however there is no efficient way to restore these indexes as mongoimport doesn't support creating indexes. Indexes need to be created manually. When needing to restore multiple collections this can take a very long time.
    It would be great if mongoimport could use this file to create indexes after an import (like mongorestore).

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Backup  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. There have been at least a few issues on Kubernetes Community Operator related to PVC expansion, yet this is not documented anywhere.

    There have been at least a few issues on Kubernetes Community Operator related to PVC expansion, yet this is not documented anywhere.

    Looking at closed issues, one may get an idea that this operation is impossible, but with the latest CSI it should be - it requires some handcrafting. On the other side Enterprise operator has this covered here - https://www.mongodb.com/docs/kubernetes-operator/stable/tutorial/resize-pv-storage/. I suggest writing similar how-to for the Community operator.
    My currently tested workflow for volume expansion is similar to this explained on the page above, but as for my knowledge Community operator doesn't allow this operation - as it will recreate StatefulSet when you delete, and there's no way for pause reconciliation of MongoDBCommunity. So it requires you to scale down operator deployment for the time of expansion.

    So it looks like this:
    1. Scale down mongodb-kubernetes-operator to 0
    2. Dump current mongodb StatefulSet specs to file
    3. Delete StatefulSet leaving pods (--cascade=orphan)
    4. Modify saved StatefulSet specs in the file and update volumeClaimTemplates to match your new size requirements

    And here it splits, as I'm using Longhorn, and it needs some time to detach and resize the volume. Because of that, using rollout - as described on the Enterprise operator hasn't worked. So for possibly any other CSI plugin, you should continue as described on the page:

    1. Patch PVCs with the new size
    2. Re-create StatefulSet with new specs for volumeClaimTemplates
    3. Rollout restart StatefulSet

    But in my case, it was like this:

    1. Delete one pod (secondary RS members first, primary last - as usual)
    2. Wait for PV to be in a detached state
    3. Patch PVC
    4. Wait for PV to resize
    5. Re-create StatefulSet with new specs for volumeClaimTemplates
    6. Wait for it to reconcile
    7. Delete StatefulSet, leaving pods again
    8. Repeat the above steps for any other pods in your StatefulSet

    And finally, make changes to MongoDBCommunity specs to match those in the manually created StatefulSet and scale-up operator.

    There have been at least a few issues on Kubernetes Community Operator related to PVC expansion, yet this is not documented anywhere.

    Looking at closed issues, one may get an idea that this operation is impossible, but with the latest CSI it should be - it requires some handcrafting. On the other side Enterprise operator has this covered here - https://www.mongodb.com/docs/kubernetes-operator/stable/tutorial/resize-pv-storage/. I suggest writing similar how-to for the Community operator.
    My currently tested workflow for volume expansion is similar to this explained on the page above, but as for my knowledge Community operator doesn't allow this operation - as… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    planned  ·  AdminDan (Admin, MongoDB) responded

    Planned - no fixed date but likely complete within Q2.

19. Allow create/delete/update custom database role in MongoDB CLI for Ops Manager

    In Altas CLI, the command customDbRoles can be used for create/delete/update custom database role.
    Would it implement in MongoDB CLI for Ops Manger?

    4 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  MongoDB CLI for Cloud Manager and Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Ability to start the bi connector using a .drdl file in Ops Manager

    Ability to start the bi connector using a .drdl file in Ops Manager. Currently only possible with en premise bi connector deployment(mongosqld).

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close