Terraform-provider-aws: Can't deploy MySQL 5.7 Aurora clusters InvalidParameterCombination: Cannot find version 5.7.mysql_aurora.2.03.2 for aurora

[bhechinger]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.12
+ provider.aws v2.33.0

Affected Resource(s)

• aws_rds_cluster_instance

Terraform Configuration Files

provider "aws" {
  version = "~> 2.0"
  region = "us-east-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "subnet-1a" {
  vpc_id = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  availability_zone = "us-east-1a"

  tags = {
    Name = "subnet-1a"
  }
}

resource "aws_subnet" "subnet-1b" {
  vpc_id = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
  availability_zone = "us-east-1b"

  tags = {
    Name = "subnet-1b"
  }
}

resource "aws_subnet" "subnet-1c" {
  vpc_id = aws_vpc.main.id
  cidr_block = "10.0.3.0/24"
  availability_zone = "us-east-1c"

  tags = {
    Name = "subnet-1c"
  }
}

resource "aws_db_subnet_group" "aurora_subnet_group" {
  name = "aurora_db_subnet_group"
  description = "Allowed subnets for Aurora DB cluster instances"
  subnet_ids = [
    aws_subnet.subnet-1a.id,
    aws_subnet.subnet-1b.id,
    aws_subnet.subnet-1c.id
  ]
}

resource "aws_rds_cluster" "default" {
  cluster_identifier = "aurora-cluster-demo"
  engine = "aurora-mysql"
  engine_version = "5.7.mysql_aurora.2.03.2"
  availability_zones = [
    "us-east-1a",
    "us-east-1b",
    "us-east-1c"]
  database_name = "mpos"
  master_username = "root"
  master_password = "SUPERSEKRITPASSWORD"
  backup_retention_period = 5
  preferred_backup_window = "07:00-09:00"
  db_subnet_group_name = aws_db_subnet_group.aurora_subnet_group.name
}

resource "aws_rds_cluster_instance" "aurora_cluster_instance" {
  count = 3

  identifier = "aurora-instance-${count.index}"
  cluster_identifier = aws_rds_cluster.default.id
  instance_class = "db.t2.small"
  db_subnet_group_name = aws_db_subnet_group.aurora_subnet_group.name
  publicly_accessible = false

  lifecycle {
    create_before_destroy = true
  }
}

Debug Output

https://gist.github.com/bhechinger/270be3f8d28fb0e37ec72af739164762

Expected Behavior

Terraform should have created the RDS instances

Actual Behavior

Terraform didn't create the RDS instances

Steps to Reproduce

1. terraform apply

Important Factoids

This is a clean account with nothing else in it. I had this issue in the past with 0.10 or 0.11 but I no longer remember the details. I'm very surprised this is still happening as that was well over a year ago.

This isn't some fancy example, either. This is pulled straight out of the terraform documentation and yet doesn't work.

I tried bumping the version up to 5.7.mysql_aurora.2.04.6 but that has the same exact behavior.

[bhechinger]

So what it looks like is somehow it's setting the engine to aurora when it makes the call to AWS instead of setting it to aurora-mysql which angers AWS as that's not a valid combination.

Digging through the code now to try and figure out why but I have never looked at a terraform provider before so this is slow going. :)

2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4: 2019/10/21 15:31:57 [DEBUG] Creating RDS DB Instance opts: {
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   AutoMinorVersionUpgrade: true,
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   CopyTagsToSnapshot: false,
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   DBClusterIdentifier: "aurora-cluster-demo",
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   DBInstanceClass: "db.t2.small",
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   DBInstanceIdentifier: "aurora-instance-2",
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   DBSubnetGroupName: "aurora_db_subnet_group",
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   Engine: "aurora",
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   PromotionTier: 0,
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   PubliclyAccessible: false,
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4:   Tags: []
2019-10-21T15:31:57.379-0400 [DEBUG] plugin.terraform-provider-aws_v2.33.0_x4: }

[bhechinger]

Ok, so adding:

  engine = "aurora-mysql"
  engine_version = "5.7.mysql_aurora.2.03.2"

to the aws_rds_cluster_instance block as well works. I don't know, however, if this is correct behavior and a documentation error or if the instance should be getting the engine/version from the cluster.

[chenbr]

Bump..

Ok, so adding:

  engine = "aurora-mysql"
  engine_version = "5.7.mysql_aurora.2.03.2"

to the aws_rds_cluster_instance block as well works. I don't know, however, if this is correct behavior and a documentation error or if the instance should be getting the engine/version from the cluster.

Bump.. just hit this as well.. any timeline for a fix?

[alexwlchan]

I think this is the code where Terraform reads the engine/engine version, which is done entirely on the basis of the supplied attributes, not the aws_rds_cluster resource:

https://github.com/terraform-providers/terraform-provider-aws/blob/acc6a21a3bd6159f4f8c10a86bcd08e70edce4f2/aws/resource_aws_rds_cluster_instance.go#L218-L227

You do have access to an RDS client (conn := meta.(*AWSClient).rdsconn), but trying to work out the correct engine type/version could be fiddly.

• What if the user supplies an engine parameter that doesn't match the RDS cluster?
• What if the user creates an aws_rds_cluster without an engine parameter, then aws_rds_cluster_instance that sets a non-default engine parameter?
• What if the user is creating the aws_rds_cluster at the same time as the instances, so you have to go digging through Terraform state to find out what engine the about-to-be-created cluster will use?

Not to say it can't be done, but it's probably not an easy patch.

I’ve just run into this problem, possibly from working the same example that @bhechinger was hitting (https://www.terraform.io/docs/providers/aws/r/rds_cluster_instance.html). As a short-term fix, what about making this small change to the example:

 resource "aws_rds_cluster_instance" "cluster_instances" {
   count              = 2
   identifier         = "aurora-cluster-demo-${count.index}"
   cluster_identifier = "${aws_rds_cluster.default.id}"
   instance_class     = "db.r4.large"
+  engine             = "${aws_rds_cluster.engine}"
+  engine_version     = "${aws_rds_cluster.engine_version}"
 }

 resource "aws_rds_cluster" "default" {
   cluster_identifier = "aurora-cluster-demo"
   availability_zones = ["us-west-2a", "us-west-2b", "us-west-2c"]
   database_name      = "mydb"
   master_username    = "foo"
   master_password    = "barbut8chars"
 }

It highlights that the two need to match, and anybody who copies and then adapts the example is going to get the correct behaviour. This would probably have helped me avoid making the same mistake, or at least caught it sooner.

What do other people think?

[eduardopuente]

same problem here, doing what @alexwlchan says works. Would be great to have this working without the engine and engine_version in the aws_rds_cluster_instance resource