Skip to content
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

Upgrading Global Database Clusters Yields Inconsistent Plan #425

Open
1 task done
theherk opened this issue Jan 25, 2024 · 6 comments · May be fixed by #426
Open
1 task done

Upgrading Global Database Clusters Yields Inconsistent Plan #425

theherk opened this issue Jan 25, 2024 · 6 comments · May be fixed by #426

Comments

@theherk
Copy link
Contributor

theherk commented Jan 25, 2024

Description

There is an issue with global database clusters that is documented in the provider but not yet accounted for in the module. It only appears when both using global clusters and when upgrading to a new engine version. And even then... not always; it is inconsistent.

Given an implementation:

module "this" {
  source  = "terraform-aws-modules/rds-aurora/aws"
  version = "~> 7.1.0"
  name    = "${var.ctx.prefix_regional}-${var.name}"

  allowed_cidr_blocks                   = var.subnet_cidrs
  apply_immediately                     = true
  allow_major_version_upgrade           = var.allow_major_version_upgrade
  auto_minor_version_upgrade            = var.auto_minor_version_upgrade
  backup_retention_period               = var.backup_retention_period
  copy_tags_to_snapshot                 = var.copy_tags_to_snapshot
  create_db_subnet_group                = true
  create_security_group                 = false
  database_name                         = var.database_name
  db_parameter_group_name               = var.db_cluster_db_instance_parameter_group_name != null ? var.db_cluster_db_instance_parameter_group_name : aws_db_parameter_group.this[0].id
  db_cluster_parameter_group_name       = var.db_cluster_parameter_group_name != null ? var.db_cluster_parameter_group_name : aws_rds_cluster_parameter_group.this[0].id
  deletion_protection                   = var.deletion_protection
  enabled_cloudwatch_logs_exports       = var.enabled_cloudwatch_logs_exports
  engine                                = "aurora-postgresql"
  engine_mode                           = var.engine_mode
  engine_version                        = var.engine_version
  global_cluster_identifier             = var.global_cluster_identifier
  instances                             = var.instances
  instance_class                        = var.instance_class
  is_primary_cluster                    = var.is_primary_cluster
  kms_key_id                            = var.kms_key_id
  performance_insights_enabled          = var.performance_insights_enabled
  performance_insights_kms_key_id       = var.performance_insights_enabled ? var.performance_insights_kms_key_id : null
  performance_insights_retention_period = var.performance_insights_enabled ? var.performance_insights_retention_period : null
  port                                  = var.port
  preferred_backup_window               = var.preferred_backup_window
  preferred_maintenance_window          = var.preferred_maintenance_window
  serverlessv2_scaling_configuration    = var.instance_class != "db.serverless" ? {} : var.scaling_configuration
  storage_encrypted                     = true
  subnets                               = var.subnet_ids
  vpc_id                                = var.vpc_id
  vpc_security_group_ids                = [aws_security_group.this.id]
}

If the variable engine_version is changed to upgrade the cluster, we usually get the error given further down.

Set aside that this isn't the latest version. I have worked with that as well, and will. The issue, I believe, is here. This needs engine_version to be ignored in the case of global clusters. However, since dynamic lifecycle blocks are not supported, the change I'm proposing is to have both aws_rds_cluster.this and aws_rds_cluster.this_ignore_engine_version. Then in the locations that reference this resource, add a ternary to select the correct instance of the resource.

What are your thoughts, @antonbabenko? Maybe there is a more simple workaround I'm overlooking.

  • ✋ I have searched the open/closed issues and my issue is not listed.

Versions

  • Module version [Required]: ~> 7.1.0" and 9.0.0
  • Terraform version: 1.5.7 and 1.6.6
  • Provider version(s):
    • provider registry.terraform.io/hashicorp/aws v5.33.0
    • provider registry.terraform.io/hashicorp/external v2.3.2
    • provider registry.terraform.io/hashicorp/local v2.4.1
    • provider registry.terraform.io/hashicorp/null v3.2.2
    • provider registry.terraform.io/hashicorp/random v3.6.0

Expected behavior

I expect this to happen given the note in the provider. What I would expect given the proposed change is that the isn't an inconsistent plan and all upgrades go well.

Actual behavior

The error is given as documented in the provider.

│ Error: Provider produced inconsistent final plan
│
│ When expanding the plan for module.ocf_pg_db.module.this.aws_rds_cluster.this[0] to include new values learned so far during apply, provider "registry.terraform.io/hashicorp/aws" produced an invalid new value for .engine_version: was
│ cty.StringVal("15.5"), but now cty.StringVal("13.6").
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

This is because when upgrading a global cluster, AWS upgrades the members, then when terraform attempts to upgrade the member, if that happens in a certain order the state of the member is not the same as in the state. Ignoring the change to engine_version in the member cluster would avoid the issues.

theherk added a commit to theherk/terraform-aws-rds-aurora that referenced this issue Feb 1, 2024
…es to global clusters.

Fix terraform-aws-modules#425. A much more thorough explanation is provided in examples/global-cluster/README.md.
theherk added a commit to theherk/terraform-aws-rds-aurora that referenced this issue Feb 1, 2024
…upgrades to global clusters.

Fix terraform-aws-modules#425. A much more thorough explanation is provided in examples/global-cluster/README.md.

Update documentation via pre-commit for global_upgradable.
Copy link

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label Feb 25, 2024
theherk added a commit to theherk/terraform-aws-rds-aurora that referenced this issue Mar 3, 2024
…upgrades to global clusters.

Fix terraform-aws-modules#425. A much more thorough explanation is provided in examples/global-cluster/README.md.

Update documentation via pre-commit for global_upgradable.
@theherk
Copy link
Contributor Author

theherk commented Mar 3, 2024

This issue isn't stale aside from its resolution awaiting review.

@github-actions github-actions bot removed the stale label Mar 4, 2024
Copy link

github-actions bot commented Apr 4, 2024

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label Apr 4, 2024
@theherk
Copy link
Contributor Author

theherk commented Apr 4, 2024

Same as before. The resolution is awaiting review.

@github-actions github-actions bot removed the stale label Apr 5, 2024
Copy link

github-actions bot commented May 5, 2024

This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days

@github-actions github-actions bot added the stale label May 5, 2024
@theherk
Copy link
Contributor Author

theherk commented May 10, 2024

Still alive and awaiting feedback.

@github-actions github-actions bot removed the stale label May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant