mongodb / terraform-provider-mongodbatlas

Terraform MongoDB Atlas Provider: Deploy, update, and manage MongoDB Atlas infrastructure as code through HashiCorp Terraform
https://registry.terraform.io/providers/mongodb/mongodbatlas
Mozilla Public License 2.0
241 stars 169 forks source link

[Bug]: Additional backup copies should be disabled if copy_settings are not provided #2385

Closed Frank-Reichenbach closed 3 months ago

Frank-Reichenbach commented 3 months ago

Is there an existing issue for this?

Provider Version

v1.15.3 and v1.17.3

Terraform Version

v1.9.0

Terraform Edition

Terraform Open Source (OSS)

Current Behavior

When I change my resource configuration for the mongodbatlas_cloud_backup_schedule resource, I expected, that when I omit the copy_settings section, it would turn off the ADDITIONAL BACKUP COPIES for my backup policies, but it didn't.

I have 2 different backup policies, one "advanced" which provides the copy_settings section to create additional copies of the backup snapshots, and another one which doesn`t. After creating a mongodbatlas_cloud_backup_schedule with the copy_settings provided, it turns on the ADDITIONAL BACKUP COPIES correctly. But switching back to my basic backup policies, without the copy_settings, it did not turn off the ADDITIONAL BACKUP COPIES, as I expected.

Terraform configuration to reproduce the issue

terraform {
  required_version = ">= 1.8.5, < 2.0.0"
  required_providers {
    mongodbatlas = {
      "source" = "mongodb/mongodbatlas"
      version  = "~> 1.15.3" # I tested with versions v1.15.3 and v1.17.3
    }
  }
}

provider "mongodbatlas" {
  private_key = local.mongodb_private_key
  public_key  = local.mongodb_public_key
}

locals {
  # please provide valid config
  my_mongodb_project_id = ""
  mongodb_private_key = ""
  mongodb_public_key = ""

  # this flag should turn off ADDITIONAL BACKUP COPIES when set to false
  advanced_backup_enabled = true
  advanced_backup = local.advanced_backup_enabled ? { enabled = true } : {}
}

resource "mongodbatlas_advanced_cluster" "main" {
  project_id             = local.my_mongodb_project_id
  name                   = "test"
  cluster_type           = "REPLICASET"
  mongo_db_major_version = "7"
  pit_enabled            = local.advanced_backup_enabled
  backup_enabled         = true
  replication_specs {
    region_configs {
      electable_specs {
        instance_size = "M10"
        node_count    = 3
      }
      provider_name = "AZURE"
      priority      = 7
      region_name   = "GERMANY_WEST_CENTRAL"
    }
  }
}

resource "mongodbatlas_cloud_backup_schedule" "backup" {
  project_id   = local.my_mongodb_project_id
  cluster_name = mongodbatlas_advanced_cluster.main.name

  dynamic "policy_item_hourly" {
    for_each = local.advanced_backup
    content {
      frequency_interval = 1
      retention_unit     = "days"
      retention_value    = 3
    }
  }

  policy_item_daily {
    frequency_interval = 1
    retention_unit     = "days"
    retention_value    = 7
  }

  dynamic "copy_settings" {
    for_each = local.advanced_backup
    content {
      cloud_provider = "AZURE"
      frequencies = [
        "DAILY"
      ]
      region_name         = "EUROPE_WEST"
      replication_spec_id = mongodbatlas_advanced_cluster.main.replication_specs.*.id[0]
      should_copy_oplogs  = true
    }
  }
}

Steps To Reproduce

  1. apply the config above with: local.advanced_backup_enabled=true
  2. check the ADDITIONAL BACKUP COPIES for the backup policy, this is turned on (as expected)
  3. apply the config above with: local.advanced_backup_enabled=false
  4. ADDITIONAL BACKUP COPIES should be turned off, but the setting is not applied to the backup policy, although tf apply finished without errors

Logs

No errors, apply works, but does not change the setting in mongodb atlas.

Code of Conduct

github-actions[bot] commented 3 months ago

Thanks for opening this issue! Please make sure you've followed our guidelines when opening the issue. In short, to help us reproduce the issue we need:

The ticket CLOUDP-259859 was created for internal tracking.

Frank-Reichenbach commented 3 months ago

Wow, thats not even 24h after I created the issue. Thank you for the prompt resolution of the issue, can't wait to see the new release!

EspenAlbert commented 3 months ago

@Frank-Reichenbach thank you for opening this issue and the clear reproduction details! The fix should be part of the next release 👍

Frank-Reichenbach commented 2 months ago

Wir haben auf das neue Release v1.17.4 aktualisiert und getestet, funktioniert wie erwartet 👍