Skip to content

fix: Sets default value for WithDefaultAlertsSettings during state import #3105

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

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

EspenAlbert
Copy link
Collaborator

@EspenAlbert EspenAlbert commented Feb 25, 2025

Description

Link to any related issue(s): CLOUDP-302586 & #3103

User impact:

During Update

State Value User Config Action Outcome
true Add with_default_alerts_settings = true No plan change
true Add/Change with_default_alerts_settings = false Error (see below)
true Remove with_default_alerts_settings No plan change (UseStateForUnknown)

Error message Update:

│ Error: with_default_alerts_settings cannot be updated or set after import, remove it from the configuration or use state value.
│ 
│   with mongodbatlas_project.project,
│   on main.tf line 22, in resource "mongodbatlas_project" "project":
│   22: resource "mongodbatlas_project" "project" {
│ 
│ The current state value is true

During Import

Import works, but the user will always get an error if with_default_alerts_settings is defined in their config and they run terraform plan for example:

resource "mongodbatlas_project" "project" {
  name                          = "testAtlasImport"
  org_id                        = var.org_id
  with_default_alerts_settings  = false
}

Error message:

mongodbatlas_project.project: Preparing import... [id=67bd8d6dbd053c5a1ee1a28c]
mongodbatlas_project.project: Refreshing state... [id=67bd8d6dbd053c5a1ee1a28c]

│ Error: with_default_alerts_settings cannot be updated or set after import, remove it from the configuration or use state value.
│ 
│   with mongodbatlas_project.project,
│   on main.tf line 22, in resource "mongodbatlas_project" "project":
│   22: resource "mongodbatlas_project" "project" {
│ 
│ The current state value is <null>

Is this a breaking change?

Arguments for Yes:

  1. Users could update the configuration before without getting an error, although it had no effect on the API.

Arguments for No:

  1. Users upgrading their provider version will see no plan changes. The previous implementation always stored the same value as the one set in the config. (It is impossible for us to know if this value match the one set during Create)

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 25, 2025
@EspenAlbert EspenAlbert marked this pull request as ready for review February 25, 2025 10:18
@EspenAlbert EspenAlbert requested review from a team as code owners February 25, 2025 10:18
Copy link
Contributor

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

…ore in project tests when it is not set to `false` in earlier steps
// we need to reset defaults from what was previously in the state:
// https://discuss.hashicorp.com/t/boolean-optional-default-value-migration-to-framework/55932
projectPlanNewPtr.WithDefaultAlertsSettings = projectPlan.WithDefaultAlertsSettings
// After import the state&plan will be null so we set to true (default value)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The user will still get a plan change after import if they have set with_default_alert_settings=false in their config. But we don't have access to that information in the import

Copy link
Collaborator

Choose a reason for hiding this comment

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

Since this is still a possibility, I'm thinking if we should even implement this fix. This sounds like it should be expected behavior that WithDefaultAlertsSettings will not be set during import and maybe something we can call out in our documentation instead.

I'd find it harder to explain to users why import shows an update if with_default_alert_settings=false in their config but works when it's true.

if projectPlanNewPtr.WithDefaultAlertsSettings.IsNull() && projectPlan.WithDefaultAlertsSettings.IsNull() {
projectPlanNewPtr.WithDefaultAlertsSettings = types.BoolValue(true)
} else {
// Force value from plan as this is not returned from the API to avoid inconsistent result errors
Copy link
Collaborator

Choose a reason for hiding this comment

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

it just feels a workaround from an API limitation, have we reached out to the team owning this feature?

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 understand is a create-only parameter that has a side effect of creating alert settings, but I'll check with upstream. Api Docs

@marcosuma
Copy link
Collaborator

@EspenAlbert nit: can we have a why in the summary section to explain the change? also let's hold this merge until we have a conversation with the upstream team (if we did, we should connect the CLOUDPs and understand the why on their side)

Copy link
Contributor

@kanchana-mongodb kanchana-mongodb left a comment

Choose a reason for hiding this comment

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

LGTM

@EspenAlbert
Copy link
Collaborator Author

Will get back to this on Wednesday

planmodifier.Bool
}

func CreateOnlyAttributePlanModifier() Modifier {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we add a comment on what this plan modifier does & why it's needed?

Copy link
Contributor

This PR has gone 7 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!

@github-actions github-actions bot added the stale label Mar 12, 2025
@EspenAlbert EspenAlbert added the not_stale Not stale issue or PR label Mar 12, 2025
orgID = os.Getenv("MONGODB_ATLAS_ORG_ID")
projectOwnerID = os.Getenv("MONGODB_ATLAS_PROJECT_OWNER_ID")
projectName = acc.RandomProjectName()
importResourceName = resourceName + "2"
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This test case is a bit different than usual, I tried to add comments, but let me know if anything is unclear.

Copy link
Collaborator

@marcosuma marcosuma left a comment

Choose a reason for hiding this comment

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

@EspenAlbert let's hold on this one. I am not too convinced we are doing the right thing in adding more complexity to handle something like this. Let's chat in today's tech sync.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug not_stale Not stale issue or PR stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants