Skip to Main Content

MongoByte MongoDB Logo

Welcome to the new MongoDB Feedback Portal!

{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.

Status Will Not Implement
Categories Atlas
Created by Guest
Created on Dec 31, 2021

mongodbatlas_cluster should wait until cluster is operational

`mongodbatlas_cluster` is regarded "created" before it's operational, which breaks things if you need to use attributes that aren't yet available, like `connection_strings`. This issue is acknowledged in the provider docs: > connection_strings - Set of connection strings that your applications use to connect to this cluster. More info in Connection-strings. Use the parameters in this object to connect your applications to this cluster. To learn more about the formats of connection strings, see Connection String Options. NOTE: Atlas returns the contents of this object after the cluster is operational, not while it builds the cluster. > > (...) > > Private connection strings may not be available immediately as the reciprocal connections may not have finalized by end of the Terraform run. If the expected connection string(s) do not contain a value a terraform refresh may need to be performed to obtain the value. One can also view the status of the peered connection in the Atlas UI.
  • Attach files
  • Guest
    Feb 24, 2022
    Hi Gus, Thank you for the submission. The provider does wait until the cluster creation is complete before it returns. The note on connection_strings is more about the status of the value being empty until the cluster is fully created, e.g. if you run Terraform on the command line you'll see the status of the cluster continue to print till it is done, Terraform won't actually have the value for connection_strings till that part is completed. We'd had users try to get and use that value before the cluster was completed and hence the docs add. There are times some connection strings can't be known even when the cluster itself is created, and that's when using private connections. The second note you have here is about that. We have no plans to wait till that is fully populated as users we've spoken with, in general, did not feel it was necessary. If that's actually what you are asking for - for the provider to wait until the private connection is completed and all connection strings are known - you may want to narrow it down to that use case.