5 results found
When MongoDB::Atlas::* resources are created and the specifed project, cluster, ... already exists, then these resources should not raise an error on resource creation but use the existing project, cluster, ... and apply the given configuration. In other words, the Create event that is initially sent by CloudFormation should be handled similar to an Update event but return the physical id of already existing resources. Apparently, this behaviour should be enabled by an opt-in flag.3 votes
VPC peering connection created by CloudFormation resource
MongoDB::Atlas::NetworkPeeringhave to accepted in AWS, using GUI, CLI etc. Would that be possible to get this done using CF only?2 votes
Would help my organization get started faster with Atlas Streams Processing1 vote
Example create database user:
- Allowed values for databaseName are admin or $external in Admin API documentation (https://www.mongodb.com/docs/atlas/reference/api-resources-spec/#tag/Database-Users/operation/createDatabaseUser)
- Corresponding CDK construct property (https://constructs.dev/packages/@mongodbatlas-awscdk/database-user/v/1.1.0/api/CfnDatabaseUserProps?lang=typescript#property.databaseName) only specifies string without further information
It would be nice to get IntelliSense in IDEs for fields which are enums behind the scenes.
Alternatively, allowed values should be included in error messages. That would make debugging at runtime easier at least.1 vote
Atlas does not currently allow to change the default write concern at the cluster level.
It it necessary to have a possibility to change it in order to avoid or minimize rollbackfiles during failover.1 vote
- Don't see your idea?