Terraform lifecycle.ignore_changes Limitation for Autoscaling Scenarios

[uni-manojkumar-n]

Hi team.

We are using the MongoDB Atlas Terraform Provider to manage multiple mongodbatlas_cluster resources. Many of these clusters have autoscaling enabled. In those cases, MongoDB Atlas may automatically change values like:

provider_instance_size_name

disk_size_gb

provider_disk_iops

To avoid Terraform constantly trying to revert these autoscaled changes, we want to use the lifecycle { ignore_changes = [...] } block. However, we only want to ignore these fields when autoscaling is enabled.

We tried making ignore_changes conditional, like:

lifecycle {
ignore_changes = var.ignore_cluster_drift ? [
"provider_instance_size_name",
"disk_size_gb",
"provider_disk_iops"
] : []
}
But this fails with the error:

Error: Invalid expression
A static list expression is required.
This is a known Terraform limitation: ignore_changes cannot accept dynamic expressions or variables.

Is there any recommended pattern or guidance from MongoDB for managing autoscaling clusters in Terraform without risking Terraform drift, but still enforcing values when autoscaling is disabled?

Do you recommend always ignoring changes to these fields for all clusters, or is there a safer workaround that works with a shared module?

Are there future improvements planned to better support this Terraform use case?

[github-actions]

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:

• Terraform configuration file used to reproduce the issue
• Terraform log files from the run where the issue occurred
• Terraform Atlas provider version used to reproduce the issue
• Terraform version used to reproduce the issue
• Confirmation if Terraform OSS, Terraform Cloud, or Terraform Enterprise deployment

The ticket CLOUDP-326569 was created for internal tracking.

[lantoli]

Thanks @uni-manojkumar-n for opening the issue.

We're aware of this issue and we are exploring different alternatives but it will take time.

I understand you're using a module to create the clusters. In that case my recommendation is to have two similar modules, one for auto-scaling clusters and one for non-auto-scaling clusters, so you have the ignore changes only in the auto-scaling cluster module.

Also I recommend that you consider migrating to mongodbatlas_advanced_cluster at some moment, you have more info in this guide.

[andresrsanchez]

We have the same scenario, we tried with one module and two mongodbatlas_advanced_cluster resources that depending on the config creates or not an autoscaled cluster but we can't "upgrade" an existing cluster to an autoscaled one because of the new resource (destroy and create in terraform)...That only works with new (autoscaled or not) clusters.

[lantoli]

thanks @andresrsanchez for your comment, yes, it's the same limitation

[github-actions]

This issue 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!

[EspenAlbert]

Adding not_stale as this continues to be a problem until we have created a workaround.
Many issues exists in the upstream Terraform CLI repo, for example this is one of them

[uni-manojkumar-n]

Thank you @lantoli for responding on this ,I have another issue ,can I post it here or I need to open new issue ,its regarding about independent shard autoscaling.

[marcosuma]

Hi @uni-manojkumar-n, please create a new one so we can keep this one specifically open to track the autoscaling scenario.

[uni-manojkumar-n]

sure @marcosuma ,new issue is created .Please look into this.

Link : #3497

[juan-vg]

Another case where this is an issue is when it's combined with a dynamic number of shards (module case). Now it's not possible to ignore the disk changes if an initial disk size wants to be set.

(same applies to instance_size and disk_iops)

Example:

resource "mongodbatlas_advanced_cluster" "this" {
  ...

  dynamic "replication_specs" {
    for_each = var.num_shards != null ? range(var.num_shards) : [0]

    content {
      region_configs {
        ...
        electable_specs {
          ...
          disk_size_gb = var.disk_size_gb
        }
        ...
        auto_scaling {
          disk_gb_enabled = true
        }
        ...
      }
      ...
    }
    ...
  }
  ...
}

[juan-vg]

Another (a bit worse) case scenario: when migrating an advanced cluster to the new sharding configurations, it's said:

This updated configuration will trigger a Terraform update plan. However, the underlying cluster will not face any changes after the apply command, as both configurations represent a sharded cluster composed of two shards.

However, since the new replication_specs block(s) get(s) the disk_size_gb value from the tf-provided value (which is a value that could have been modified by autoscaling), I'm a bit worried the plan value could not match the actual cluster value causing undesired/unplanned changes.