We have a lot of Atlas projects in our org, some are outdated, unused, orphaned, some important and used for production. It would be great to have a way to describe what each of them are for, who to contact for questions, etc.

For example, when you switch to a project, you land on the project homepage that has the description right there, alongside an overview of how many clusters, users, last change, if whitelists are enabled etc. Even better if I can use Markdown or some other "rich" editing experience to create the description and add links, bullet points, etc.

We have a situation where we are required to build in an AWS region that only has two AZs (ca-central-1). In addition, there are no other AWS regions in the country (Canada). And due to our requirement around data sovereignty, we can't host this data set within a different country.

Because of this, we can't guarantee our cluster will stay up if we lose a single AZ unless we put an arbiter in a 2nd region (since no data is copied to the arbiter). However, Atlas does not support arbiters currently. I know arbiters aren't ideal, but in this edge case, it would benefit us. With our non-Atlas MongoDB cluster we can support this model, but with Atlas, we cannot. And this may keep us from moving this particular cluster into Atlas until it is supported.

Let us know if you have any questions.

Thank you!

Atlas monitoring is great... but it would be super helpful to see a graph of banked iops. (or an approximation of this)

Suppose my iops limit is 100... and during the night my bank gets fully charged to 5.4MM.
During the heavy loads on my server, let's say my iops jump to a steady 500. This means that I am drawing 400 units from my bank. I can do this for 3.75 hours until my bank is exhausted.

It would be so helpful to see an iops bank balance drawing down during peak, recharging during off-peak... and thus getting insight as to when we need to scale up.

A Simple Undo Function.

A Bit Of Background Information

Just talked to Julia from PR. Apparently "undo" is not an available feature.

YES,

there is a backup option for higher tier customers.

But,

I am not asking for a full on log of everything. Just a simple copy of the last added or deleted document in a collection for example. In case you accidentally clicked the confirm delete button on the document, your mouse was happening to hover over, when a spider jumped down from the ceiling and landed on your mouse.
It happens.

Besides the point.

That functionality is not particularly hard to implement, nor will it cut your revenue.

Hear me out.

For atlas (web only) for example:
All that needs to be done is to save a copy of the current document you have handled, be it adding it or deleting it.
Yes,you need not necessarily save a copy of a document you created.

Besides the point.

The copy for said document, will be saved in either in cache, cookie, session storage, what ever your heart's desire.

Be it encrypted or not.

Up to you.

All I am asking is, please, for the love of god, think of the less fortunate once in a while and implement an undo feature.

"But were busy at the moment"

You may as well hire me for the job, this should not take all that long to implement.

Always open for further question or a good discussion.

Sincerely,

A doofus on the job

What is the problem that needs to be solved? Add an option (as it was in mLab) that allows to share the Cloud Provider Backup Snapshot (EBS Snapshot [1], in case of AWS) for Atlas Cluster with customer's Cloud Provider account. This action is easier, quicker and cheaper for customers than manually downloading the Atlas Snapshot.

Why is it a problem? (the pain) A) Operational pain: as of now (2020-02-18), if you require to execute disaster recovery scenario with restoration of your Atlas Cluster data outside of Atlas Clusters you'll need to create a Cloud Provider Backup Snapshot Restore job (POST /groups/[GROUP-ID]/clusters/[CLUSTER-NAME]/backup/restoreJobs/ Public API call [2]), then wait until that job will be finished and then manually download Atlas Snapshot(s) via HTTPS; B) Additional cost associated with manual restoration procedure: in order to know which Backup Snapshot file is related to which Shard/CSRS you'll need to download it, untar and check mapping.

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html
[2] https://docs.atlas.mongodb.com/reference/api/cloud-provider-snapshot-restore-jobs-create-one/