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

bhechinger commented 5 years ago

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

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

justinretzolk commented 3 years ago

Hey @bhechinger 👋 Thank you for taking the time to file this issue. Given that there's been a number of AWS provider releases since you initially filed it, can you confirm whether you're still experiencing this issue?

bhechinger commented 3 years ago

Wow, it's been a while since I was even doing this! 🤣

I will do some testing for you, however. It's the least I could do.

justinretzolk commented 3 years ago

@bhechinger We appreciate it a ton! Apologies for the delay in getting back to you; we're doing quite a lot of work in trying to better that experience (including my being in this dedicated role 😃). I'll keep an eye out for any updates you may have.

edlinklater commented 2 years ago

Just confirming that I've run into the same issue just now, so it still seems to be an issue running latest 3.x.

be4ndr commented 2 years ago

I found a root cause. Amazon changed an engine name for Aurora MySQL 2.x https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.20180206.html#AuroraMySQL.Updates.20180206.CLI The engine name for Aurora MySQL 2.x is aurora-mysql; the engine name for Aurora MySQL 1.x continues to be aurora.

So in my case when I used these variables terraform successfully built Aurora RDS. aurora_engine = "aurora-mysql" aurora_engine_version = "5.7.mysql_aurora.2.10.1"

hashicorp / terraform-provider-aws