[DOCS-13211] Terraform documentation for Azure unclear - `disk_size_gb` cannot be used with Azure clusters - Harmonize with API documentation Created: 08/Nov/19  Updated: 29/Oct/23  Resolved: 11/Nov/19

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

Type: Improvement Priority: Major - P3
Reporter: Julian Storz Assignee: Melissa Plunkett
Resolution: Fixed Votes: 0
Labels: api, terraform
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MongoDB Atlas on Azure - Terraform


Participants:
Days since reply: 4 years, 13 weeks, 1 day ago

 Description   

Description

Customers have been raising the issue, that the documentation for Terraform is unclear as they were running into errors when using the Terraform Provider.

Error: `disk_size_gb` cannot be used with Azure cluster

The reason is that Azure only provides the disk types.

This is more clearly defined in the API documentation - suggestion is to harmonise the two documentations and also transfer the table from the API documentation also to the Terraform documentation to make this clear:
https://docs.atlas.mongodb.com/reference/api/clusters-create-one/

providerSettings
.diskTypeName
string Azure Required Azure disk type of the server’s root volume. If omitted, Atlas uses the default disk type for the selected providerSettings.instanceSizeName.
The following table lists the possible values for this field, and their corresponding storage size.
diskTypeName Storage Size
P4 1 32GB
P6 64GB
P10 2 128GB
P20 512GB
P30 1024GB
P40 2048GB
P50 4095GB

1 Default for M20 and M30 Azure clusters
2 Default for M40+ Azure clusters|

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Julian Storz [ 12/Nov/19 ]

melissa.plunkett

Thank You

Comment by Melissa Plunkett [ 11/Nov/19 ]

julian.storz - PR to adjust this https://github.com/terraform-providers/terraform-provider-mongodbatlas/pull/66

Comment by Julian Storz [ 11/Nov/19 ]

melissa.plunkett - Yes this should be sufficient.

I think the core reason for the confusion was, that it was not clear, that not all the flags are available for all cloud providers.
The key part is that it is clear, how the single components of the underlying infrastructure can be managed via Terraform.

In this case, that the disk allocation in Azure is defined using the diskTypeName rather than disk_size_gb.
Maybe just also flag this in the Azrue example - as seeing "P6" is not intuitive to me that this means: 64 GB.

If the point you mentioned can also be noted - this would be very helpful.

Thank you for your help!

Comment by Melissa Plunkett [ 08/Nov/19 ]

julian.storz - question for you, the Azure example does not have disk_size_gb:

https://www.terraform.io/docs/providers/mongodbatlas/r/cluster.html#example-azure-cluster-

Example Azure cluster.

resource "mongodbatlas_cluster" "test"

{ project_id = "<YOUR-PROJECT-ID>" name = "test" num_shards = 1 replication_factor = 3 backup_enabled = true auto_scaling_disk_gb_enabled = true mongo_db_major_version = "4.0" //Provider Settings "block" provider_name = "AZURE" provider_disk_type_name = "P6" provider_instance_size_name = "M30" provider_region_name = "US_EAST_2" }

So is it just that we should update the attribute disk_size_db that it is only for GCP/AWS? Just want to make sure I know where the confusion comes from.

Comment by Melissa Plunkett [ 08/Nov/19 ]

julian.storz thank you for submitting this. The documentation for Terraform was written by our contractor from our API docs but simplified as per the Terraform standard doc style (one can look at the underlying API docs which are linked to in many places). Hence it isn't our docs team maintaining this. I will work on a some improvements to make this information more clear but it is unlikely we will copy too much of our underlying docs to the Terraform hosted docs (that means updating two very seperate places on each change).

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