When creating an index on your UI, if the index creation gives an error, the error doesn't show on the UI, for example if you have a field of type string, and have a value longer than 1024 bytes, and try to create a normal index on this field, the UI will tell you the index it's been creating successfully, but when you go to your collection and see your indexes, this will not appear, but when you create it on the MongoDB console, it gives the following error. It would be nice to have this error shown on the UI

WiredTigerIndex::insert: key too large to index, failing 2864 { : "TXQAAE10ABdjb20uY2F1Y2hvLm5hbWluZy5RTmFtZVMACF9jb250ZXh0TXQAJ2phdmF4Lm5hbWluZy5zcGkuQ29udGludWF0aW9uRGlyQ29udGV4dFMAA2NwZU10ACNqYXZheC5uYW1pbmcuQ2Fubm..." }

We're currently using the Atlas Service Broker (https://github.com/mongodb/atlas-osb) which is built using the native Atlas REST APIs.

In the project creation, it creates the project using the POST /api/atlas/v1.0/groups endpoint via an API key. As a result, we have an unexpected user added as the project_owner of the project.

THis is due to:
IMPORTANT

To create a project using API Key credentials, you must specify an orgId. When you do, Atlas automatically selects the Owner of the specified organization with the earliest account creation date and time as the Project Owner for the newly created project.

The API should be expanded to allow for a user to be configured as the default project owner, or the project should not require a default project_owner at all when it is created via an API.

A cross-region peering connection, say from an Atlas cluster in us-east-1 to some application running in eu-west-1, should allow the application to connect to the Atlas cluster through the peering connection. However, the DNS names of the cluster, e.g. my-cluster-shard-00-00.abx.mongodb.net, resolve to the public IP address of the cluster's node when looked up in eu-west-1. As a result, the application doesn't route the connection through the peering connection but rather tries to route it through the public Internet.

The solution is to manually find the private IP of each mongo node, and add an entry in /etc/hosts for each. This isn't straight forward and takes some work.

The current REST API requires many queries to get all of the information needed for a simple thing. For example, if I want to pull logs for a cluster called My-Cluster in a project called My-Project, I need to....

• GET the list of projects from the organization
• Parse the result to locate the Project ID for My-Project
• GET the list of clusters in My-Project
• Parse the result to locate the cluster nodes that I need to grab logs for
• For each node in the cluster:
  • GET the log(s) for that node

At least the first four steps described here could be reduced to a single call with a GraphQL API that would return only the list of nodes.

The resulting reduction in queries would mean fewer and easier queries for API users and lower load on your API infrastructure.