-
Notifications
You must be signed in to change notification settings - Fork 206
doc: Adds examples for advanced_cluster upgrade to v2.0 & improves documentation #3767
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
base: master
Are you sure you want to change the base?
Conversation
|
||
Note: Once applied, the `mongodbatlas_advanced_cluster` resource making use of the new sharding configuration will not be able to transition back to the old sharding configuration. | ||
|
||
## Who should read this guide? |
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: this section may have some redundancy with the "Objective" in each guide, but will wait for the team for review first.
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'd probably follow the Objective style as in the other guides
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.
could you clarify what you mean by "objective style"?
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 mean we start many of the guides with an Objetive section, e.g.: https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/guides/cluster-to-advanced-cluster-migration-guide
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.
Right, there is some overlap between the two but still think we need a separate section because there are various guides that can be confusing for users, so this section is supposed to serve more as an index
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.
ok
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.
Usually I would advise to combine these sections but I agree with @maastha that there is a lot of info here so I think it works
APIx bot: a message has been sent to Docs Slack channel |
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 updates MongoDB Atlas provider documentation and examples to reflect the upgrade from v1.x to v2.0.0, removing references to preview functionality and updating documentation to reflect the stable release.
- Updates documentation to reference provider v2.0.0 instead of v1.29.0 preview
- Adds comprehensive examples for migrating from v1.x to v2.0.0 with side-by-side configurations
- Improves build scripts to handle different provider versions during validation
Reviewed Changes
Copilot reviewed 37 out of 38 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
scripts/tf-validate.sh | Adds conditional handling for v1.x.x directories to use remote provider instead of local override |
examples/mongodbatlas_advanced_cluster/*/README.md | Updates documentation to remove preview references and update version requirements |
examples/mongodbatlas_advanced_cluster//v1.x.x/ | Adds migration reference examples showing deprecated v1.x schema |
examples/mongodbatlas_advanced_cluster/*/versions.tf | Adds version constraints for new examples |
docs/guides/*.md | Updates migration guides with clearer targeting and improved cross-references |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
**Objective**: This guide explains how to replace the deprecated `mongodbatlas_cluster` resource with the `mongodbatlas_advanced_cluster` resource. For data source migrations, refer to the [output changes](#output-changes) section. If you're transitioning to independent sharding, additional guidance is available in the [Advanced Cluster New Sharding Configurations Migration Guide](advanced-cluster-new-sharding-schema#data-source-transition-for-asymmetric-clusters). | ||
|
||
|
||
## Who should read this guide? |
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.
same, shouldn't we use the same Objective style?
@@ -0,0 +1,83 @@ | |||
provider "mongodbatlas" { | |||
public_key = var.public_key |
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: we're releasing SA soon, and it'll be the recommended authentication method
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.
good callout! I think that can be done as a follow-up. Since it would only require updating examples in the repo (& not TF docs) it should be okay to do post-SA release, WDYT?
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.
yes, follow-up is fine
|
||
... or follow as in the `variables.tf` file and create **terraform.tfvars** file with all the variable values, ex: | ||
``` | ||
public_key = "<MONGODB_ATLAS_PUBLIC_KEY>" |
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.
similarly about SA before
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.
one minor comment but LGTM otherwise
|
||
Note: Once applied, the `mongodbatlas_advanced_cluster` resource making use of the new sharding configuration will not be able to transition back to the old sharding configuration. | ||
|
||
## Who should read this guide? |
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.
Usually I would advise to combine these sections but I agree with @maastha that there is a lot of info here so I think it works
private_key = var.private_key | ||
} | ||
|
||
resource "mongodbatlas_advanced_cluster" "cluster" { |
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] use this
instead of cluster
/project
/etc. See naming conventions
for DIR in $(find ./examples -type f -name '*.tf' -exec dirname {} \; | sort -u); do | ||
[ ! -d "$DIR" ] && continue | ||
pushd "$DIR" | ||
# For directories named like v1.x.x, do NOT use local override |
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.
Nice
}] | ||
|
||
advanced_configuration = { | ||
javascript_enabled = true |
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.
Any reasoning behind these values?
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.
Regarding the docs/guides: I think we should consider streamlining them and think of them by connecting the target configuration and what are the starting points.
For example:
- the target is mongodbatlas_advanced_cluster 2.0.0 (which includes ISS, no deprecated fields and TPF)
- the starting points are:
We should basically re-organise our guides with the following tenets:
- each starting point and target to have an how-to and an example
- each guide to have the exact same identical structure
I find, in fact, that "## Who should read this guide?" could help but it looks like a patch to what we have now instead of reorganising it to make it more intuitive.
→ Follow this guide to understand how multiple `replication_specs` blocks now represent shards individually, allowing you to scale or modify each shard independently. | ||
→ As mentioned in the [Prerequisites](#prerequisites), once you understand the new model, proceed to the [Migrate to Advanced Cluster 2.0](migrate-to-advanced-cluster-2.0) guide to update your configuration to the latest schema first in order to upgrade to provider version 2.0.0 or later. | ||
|
||
- **You currently use v1.x.x of the provider with the preview schema** (using the `MONGODB_ATLAS_PREVIEW_PROVIDER_V2_ADVANCED_CLUSTER=true` environment variable and list-style attributes): |
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 am not sure I would understand what are list-style attributes as a customer
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 understand, do you think "block" vs "attribute" may be better wording for users? Essentially, don't think we can directly say "TPF" as that's more of an implementation detail that users may not understand.
Or may be make it more descriptive with "attributes (containing of an = sign)..." or something? Tried to keep it as short as possible
Here's a proposed structure:
|
Co-authored-by: John Williams <[email protected]>
Description
Adds examples for advanced_cluster upgrade to v2.0 & improves documentation.
This PR does not contain an example for modules which will be done as a follow-up.
Link to any related issue(s):
Type of change:
Required Checklist:
Further comments