Skip to content

fix: Handles updates of mongodbatlas_global_cluster_config #3060

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

Merged
merged 12 commits into from
Feb 19, 2025
Merged

Conversation

oarbusi
Copy link
Collaborator

@oarbusi oarbusi commented Feb 12, 2025

Description

Reverts #2282 to be able to handle updates of mongodbatlas_global_cluster_config but with the following adaptations:

  • error if an existing managed_namespace entry is being modified. We can manage collection and db fields to do so.
  • for new managed_namespace entries call the POST for each of them
  • for deleted managed_namespace entries call the DELETE for each of them
  • add new custom_zone_mappings and call the POST for each of them
  • only allow custom_zone_mappings deletion if all of them are being deleted

Link to any related issue(s): CLOUDP-301529

Type of change:

  • Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
  • New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
  • Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
  • This change requires a documentation update
  • Documentation fix/enhancement

Required Checklist:

  • I have signed the MongoDB CLA
  • I have read the contributing guides
  • I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
  • I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
  • I have added any necessary documentation (if appropriate)
  • I have run make fmt and formatted my code
  • If changes include deprecations or removals I have added appropriate changelog entries.
  • If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

@github-actions github-actions bot added the bug label Feb 12, 2025
if newEntry, exists := newMap[key]; exists {
// Modification detected: key exists but value differs.
if !reflect.DeepEqual(oldEntry, newEntry) {
return diag.FromErr(fmt.Errorf("managed namespace for collection '%s' in db '%s' cannot be modified; remove it and add a new entry instead", oldEntry["collection"], oldEntry["db"]))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove it and add a new entry is incorrect. They simply can't change it and we should ask upstream updates on how to handle this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed that part of the error message. But I want to clarify that it is possible, even if not recommended, to delete and create if user wants to

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream confirmed that it's not recommended to drop and re-create to update, but possible if the user wants to do it. This is hard to avoid if we want to allow deleting and creating managed_namespaces. Which as far as I know we should allow

@nikhil-mongo
Copy link
Collaborator

I have tested this from the TSE perspective and below are the results:

  • Adding 2 managed namespaces: WORKS
  • Adding 1 more managed namespace: WORKS
  • Removing 1 managed namespace: WORKS
    • However, please note that removing a managed namespace only removes the Global Writes configuration. It still keeps the shard_key and the associated index in, which is acceptable.
  • Do not allow modifying any of the existing namespace(eg. modifying is_shard_key_unique): WORKS

@oarbusi oarbusi marked this pull request as ready for review February 13, 2025 08:17
@oarbusi oarbusi requested review from a team as code owners February 13, 2025 08:17
Copy link
Contributor

APIx bot: a message has been sent to Docs Slack channel

@@ -0,0 +1,3 @@
```release-note:enhancement
resource/mongodbatlas_global_cluster_config: Supports update operation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be easier to review if this was done in two PRs, one with the revert without any additional change, next PR with the changes, so we can spot better the real changes after the revert

if isShardKeyUnique, okShard := mn["is_shard_key_unique"]; okShard {
addManagedNamespace.IsShardKeyUnique = conversion.Pointer[bool](isShardKeyUnique.(bool))
}
_, _, err := connV2.GlobalClustersApi.CreateManagedNamespace(ctx, projectID, clusterName, addManagedNamespace).Execute()
Copy link
Collaborator

@maastha maastha Feb 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens in case this errors out for a particular namespace? Right now I think it would just fail right away and not complete the loop. Should we instead capture errors from all calls and fail once?
Same for deleting namespaces and adding custom zone mappings

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think failing right away is okay, but I haven't thought about the alternative or if we should complete the loop in case of a single failure. No strong opinion from me on this

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay failing right away. Only thing to consider is users might run follow-up updates in those cases, and as long as that works as expected and doesn't run into any state inconsistencies this should be fine.

Copy link
Member

@AgustinBettati AgustinBettati left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@oarbusi oarbusi merged commit 48c9c4e into master Feb 19, 2025
40 checks passed
@oarbusi oarbusi deleted the HELP-70971 branch February 19, 2025 09:49
svc-apix-Bot added a commit that referenced this pull request Feb 19, 2025
lantoli added a commit that referenced this pull request Feb 19, 2025
* master:
  chore: Updates CHANGELOG.md for #3060
  fix: Handles updates of `mongodbatlas_global_cluster_config` (#3060)
  chore: Updates CHANGELOG.md for #3069
  fix: Handle the deleted on the backend case correctly for `mongodbatlas_database_user` resource (#3069)
  build(deps): bump go.mongodb.org/atlas-sdk (#3082)
maastha pushed a commit that referenced this pull request Feb 20, 2025
* handle update

* change error message

* changelog

* docs change

* test changes

* Update docs/resources/global_cluster_config.md

Co-authored-by: Marco Suma <[email protected]>

* reference API

* add partial and total removal of custom_zone_mappings in test

* refactor update

* pr suggestions

* Update internal/service/globalclusterconfig/resource_global_cluster_config.go

Co-authored-by: Leo Antoli <[email protected]>

* Update docs/resources/global_cluster_config.md

Co-authored-by: John Williams <[email protected]>

---------

Co-authored-by: Marco Suma <[email protected]>
Co-authored-by: Leo Antoli <[email protected]>
Co-authored-by: John Williams <[email protected]>
maastha pushed a commit that referenced this pull request Feb 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants