[DOCS-11832] clusterType missing from response objects of create and modify cluster endpoints. Created: 25/Jun/18  Updated: 29/Oct/23  Resolved: 05/Jul/18

Status: Closed
Project: Documentation
Component/s: API, Atlas
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Robert Justice (Inactive) Assignee: Robert Justice (Inactive)
Resolution: Fixed Votes: 0
Labels: triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Participants:
Days since reply: 5 years, 33 weeks, 1 day ago
Story Points: 0.1

 Description   

----------------------------

Original Description

Documentation for the create and modify cluster endpoints are missing the clusterType in the response objects.  Likely missing from request body as well. Need to verify valid values with engineering devs.

https://docs.atlas.mongodb.com/reference/api/clusters-create-one/ (request and response)

https://docs.atlas.mongodb.com/reference/api/clusters-modify-one/ (request and response)

https://docs.atlas.mongodb.com/reference/api/clusters-get-one/#response (response object)

https://docs.atlas.mongodb.com/reference/api/clusters-get-all/ (response object)

----------------------------

Description

Scope of changes (files that need work and how much)

Impact to other docs outside of this product

MVP (work and date?)

Resources (e.g. Scope Docs, Invision)



 Comments   
Comment by Vincent Do [ 26/Jun/18 ]

Actually, there is an additional caveat. If the user provide a clusterType field with a non-sensical topology, we should have validation that will return some sensible message. For instance:
REPLICASET with numShards > 1
SHARDED with numShards < 2

Comment by Vincent Do [ 26/Jun/18 ]

The clusterType field is only required in the request body parameter when a user is trying to provision a geo sharded (aka global write) cluster. The possible values are REPLICASET, SHARDED, and GEOSHARDED. The field will always be present in the response body.

Generated at Thu Feb 08 08:03:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.