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.

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.