-
Notifications
You must be signed in to change notification settings - Fork 1
feat: Don't use num_shards and root disk_size_gb in conversion #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR modifies the Terraform advanced cluster to v2 conversion logic to exclude num_shards and root-level disk_size_gb attributes from the conversion process. The change addresses limitations in handling non-numerical num_shards values and improves disk size handling by distributing root-level disk_size_gb values to individual specs.
Key changes:
- Remove
num_shardsfrom replication specs during conversion and expand specs based on shard count - Extract and distribute root-level
disk_size_gbto individual electable, read-only, and analytics specs - Add error handling for non-numerical
num_shardsvalues
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| internal/convert/adv2v2.go | Core conversion logic updated to handle num_shards expansion and disk_size_gb distribution |
| internal/convert/const.go | Added new error constant for root attribute handling |
| internal/convert/testdata/adv2v2/*.tf | Test files demonstrating conversion behavior for various scenarios |
| internal/convert/testdata/adv2v2/errors.json | Added error message for non-numerical num_shards handling |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
marcosuma
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ty
| "replication_specs_missing_region_configs": "replication_specs must have at least one region_configs", | ||
| "missing_replication_specs": "must have at least one replication_specs" | ||
| "missing_replication_specs": "must have at least one replication_specs", | ||
| "num_shards_not_numerical": "setting num_shards: failed to evaluate number" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the full context of this error, but not sure how I would fix it 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as in the other command we distinguish two main use cases:
- advanced_cluster used directly without a module, we expect a numerical value in num_shards
- advanced_cluster in a module, in this case we support variables in num_shards and dynamic blocks (PR will follow with this implementation).
see PR description note for more info
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the explanation!
FFTR or leave open for others
| @@ -0,0 +1,60 @@ | |||
| resource "mongodbatlas_advanced_cluster" "geo" { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nit] prefer one resource per file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a tradeoff between having a lot of small files and one big file, in this case I think it makes sense to have resources together when they test something very similar with slight variations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good
EspenAlbert
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few nit comments, but looks good!
| cluster_type = "GEOSHARDED" | ||
| replication_specs { | ||
| zone_name = "Zone 1" | ||
| num_shards = var.num_shards # unresolved num_shards |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: Could var.num_shards be used to generate a foreach of replication_specs? Ok if we have this as a known limitation but was curious if this approach could work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AgustinBettati hi, I think this is related to this comment as well.
We have it as a limitation when a plain cluster (without module) is being used as. But the loop approach is done when dynamic blocks are used, e.g. here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. But if a customer has a resource without a module and using var.num_shards, converting to using a foreach and leveraging the var.num_shards value could be possible for reaching an equivalent config right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AgustinBettati yes, I'm working on it in a follow-up PR but it's not simple. For example if there are multiple replication_specs, at least one of them with variable, then concat must be used
Description
Don't use num_shards and root disk_size_gb in conversion.
Note: Same limitation applies to num_shards as in clu2adv command:
num_shardsinreplication_specsmust be a numeric literal expression, e.g.var.num_shardsis not supported. This is to allow creating areplication_specselement per shard inmongodbatlas_advanced_cluster. This limitation doesn't apply if you're usingdynamicblocks inregions_configorreplication_specs.Link to any related issue(s): CLOUDP-339203
Type of change:
Required Checklist:
Further comments