Open bhechinger opened 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: }
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..
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?
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:
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.
engine
parameter that doesn't match the RDS cluster?aws_rds_cluster
without an engine
parameter, then aws_rds_cluster_instance
that sets a non-default engine parameter?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?
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
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?
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.
@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.
Just confirming that I've run into the same issue just now, so it still seems to be an issue running latest 3.x.
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"
Community Note
Terraform Version
Affected Resource(s)
Terraform Configuration Files
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.