Right now Mongo Atlas allows you to assign two types of roles to all the users: Organization and Project, and for each set it gives you some predefined roles.

The problem with this is you can't have any kind of granular control of what permission is assigned to each user. (e.g. to allow a user to create a trigger through Mongo Stitch it needs the Project Owner role).

This is a major setback as I'm giving my coworkers more access than needed.

A good solution would be to have something like the database access control in this part so we can create our own custom roles to assign to he users.

Hi, we have tried BETA of Autoscaling feature and we have some thoughts how to make it better. In its current setup its not really suitable for our production workloads. Here are some thoughts how to make it better:

1. Define separate scaling steps
   At them moment the scaling step is always 1. Going from M10 -> M20 which is not really suitable for burst loads where going one step up might not be enough. Same goes for rapid scaling down

Example:
Scale range = M10 - M50
Scale step up 4 = (M10 -> M50)
Scale step down 2 = (M50 -> M30 -> M10)

1. Define custom timescale
   It seems that current setup is to start scaling down after 72h, and then repeat every 24h.
   Our system can be scaled down much more rapidly, when our burst load goes away its done for a few days, we know we can start scaling down after 12h and repeat every 6h.
   With current setup it will take 6 days to scale down from M50 -> M10.




2. Define custom scaling metrics and thresholds
   It seems that current system is not taking N of connected clients as a scaling metric.



3. when connecting from cloud functions its easy to have a lot of connections which are not draining CPU or memory, when we are scaled down to M10 that limit is only 200


4. additionally we would like to scale up when our CPU limit is >50% which is not possible ATM

Nice to have:
4. Time based scaling events
scale up/down at specified time & day, useful for scaling up DEV/Research environments within working hours

PS: writing a long post in this form is terrible

I'm coming from mLab and I'm used to having an option in my backup strategy that includes a mongodump backup as well as what Atlas calls a CPS (cloud provider snapshot). The latter is actually a snapshot of the database directory at the filesystem level, which is great for instant restores within Atlas (same or different cluster). However, the mongodump backup (from mLab as an example) allows me to backup on a regular schedule and download those backups for restores locally and elsewhere outside of Atlas.

Yes, I can run mongodump operations myself from a system outside of Atlas, but having those mongodump archives available within a rolling window is really great to quickly grab a backup and examine offline or in another environment entirely, with no additional management or systems from me to do so.

Today when an Atlas cluster is deleted, all backups/snapshots of this cluster are deleted along with it.

This is especially an issue when working with automation tools like terraform, where a cluster can be deleted by accident easily.

In AWS Aurora Postgres, for example, there is an option to create a "final snapshot" before deleting the cluster.

If this option is enabled for a cluster, whenever a user triggers the deletion of the cluster (either manually, via API, or any other method), a final snapshot will be created, before the cluster is deleted.

This final snapshot is then available independently of the deleted cluster, so in case of accidental deletion, we can create a new cluster based on this snapshot.

This would be a huge security and safety improvement.

Hi,

I’m facing an issue about Snapshot Backup Policy creation/modification via Terraform ( FYI, I open a case to the support of MongoDB  https://support.mongodb.com/case/00668262). Let me explain :

When I want to create a MongoAtlas Cluster via terraform, I want to apply a custom Snahsphot Backup Policy with ONLY 2 items during the creation of the cluster :
N° Item Frequency type Frequency Retention
0 Daily 1 7 Days
1 Weekly 1 (Saturday) 4 weeks

However, during the creation of the mongo atlas cluster, I can see an error
Error: Error applying plan:

1 error occurred:

* module.cluster_contrib.module.dpjmongoatlas.module.tfmodule-gcp-mongo-atlas-cluster.mongodbatlas_cloud_provider_snapshot_backup_policy.snapshot_backup: 1 error occurred:

* mongodbatlas_cloud_provider_snapshot_backup_policy.snapshot_backup: error updating a Cloud Provider Snapshot Backup Policy: PATCH <a rel="nofollow noreferrer" href="https://cloud.mongodb.com/api/atlas/v1.0/groups/XXXXXXXXXXXXXXXXX/clusters/contrib/backup/schedule">https://cloud.mongodb.com/api/atlas/v1.0/groups/XXXXXXXXXXXXXXXXX/clusters/contrib/backup/schedule</a>: 400 (request &quot;Bad Request&quot;) The frequency type of a policy item must not be changed.

Indeed, during the creation of the MongoAtlas cluster, MongoAtlas apply the default Snapshot Backup Policy first (with 4 items hourly, daily, weekly, monthly) and after try to apply the custom snapshot backup policy I want (described in the terraform code). But, as we can see above, it seems impossible to change the frequency_type of an existing policy’s item…

To resume clearly with this spreadsheet :
N° Item Frequencytype of default policy Frequencytype of custom policy I want COMMENT
0 Hourly Daily KO (because The frequency type of a policy item must not be changed)

1 Daily Weekly KO (because The frequency type of a policy item must not be changed)

2 Weekly NOTHING
3 Monthly NOTHING

Can we purpose a evolution to have the possibilty to modify the frequency_type of an existing policy item via Terraform/API?

Regards,

Hello,

I think it would be a good idea to have team management at project level.
We have many projects and members in our Atlas account.
I'm a organization owner. The people in my organization use the Altas service. I create
a project for them and give my colleagues the project owner authorizations.

Project owners can invite other members. This is good. But it's a little inconsistent that
they are not able to create groups or teams within their projects They have to manage the permissions for each member separately.

We can't use organization teams, because they are located at the organizational level. Therefore, only the owner of an organization can create teams.
And only the owner of an organization can add or remove members from a team.

The atlas metrics show node election statuses in colors - red/orange and brown. When there are multiple re-elections in a short period of time, these all merge together making it hard to decipher the order of occurrence - especially the near overlap of orange and brown Having vivid/contrasting colors should make debugging easier.

It would be helpful if some aspect about the x-axis would tell you what status the node was in at a given time. For example: the x-axis is also that color from time X to time Y, and then the node was demoted/down and the axis turns to the appropriate color until time Z when the status changes again.