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

RDS: aws_db_instance not respecting parameter_group_name on first run #8079

Closed
alkema opened this issue Aug 9, 2016 · 4 comments
Closed

Comments

@alkema
Copy link

alkema commented Aug 9, 2016

When using aws_db_instance and setting the parameter_group_name it is presented in both plan and apply as being set with the correct value. However, after being applied the value is set to something else. When looking at the RDS instance in the AWS interface it is not set properly, it is set to default.mysql5.6, not mysql-params.

Upon an immediate subsequent terraform plan this diff is evident, then a subsequent terraform apply changes parameter_group_name to the correct value. I then need to do an RDS reboot to apply it too.

Terraform Version

✗ terraform -v
Terraform v0.7.0

Affected Resource(s)

  • aws_db_instance

Terraform Configuration Files

...
variable "parameter_group_name" {
  default = "mysql-params"
}

resource "aws_db_instance" "default" {
  lifecycle {
    create_before_destroy = true
  }
  instance_class = "${var.instance_class}"
  db_subnet_group_name = "${var.db_subnet_group_name}"
  snapshot_identifier = "${var.snapshot_identifier}"
  identifier = "${var.identifier}"
  parameter_group_name = "${var.parameter_group_name}"
  apply_immediately = true
  tags {
    Cluster = "${var.cluster}"
    Environment = "${var.environment}"
    App = "${var.app}"
  }
}
...

Expected Behavior

I expect parameter_group_name to be applied with the value it was set within the config on first apply. I also expect to have to do an AWS RDS reboot as according to docs:

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html

Parameter group name:
The name change is applied immediately. Any parameter value changes are applied to the DB instance after you manually reboot the DB instance.

Actual Behavior

parameter_group_name is set to default.mysql5.6 not mysql-params.

Steps to Reproduce

terraform plan

...
-/+ module.hampton.aws_db_instance.default
...
    parameter_group_name:       "mysql-params" => "mysql-params"

terraform apply

...
  parameter_group_name:       "" => "mysql-params"
...

terraform plan

Note: this is the only change reported.

~ module.hampton.aws_db_instance.default
    parameter_group_name: "default.mysql5.6" => "mysql-params"

terraform apply

Note: this is the only change reported.

module.hampton.aws_db_instance.default: Modifying...
  parameter_group_name: "default.mysql5.6" => "mysql-params"

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Now a manual RDS reboot needed to apply change and finally get a proper parameter_group_name.

@alkema alkema changed the title aws_db_instance not respecting parameter_group_name on first run RDS: aws_db_instance not respecting parameter_group_name on first run Sep 12, 2016
@kxseven
Copy link

kxseven commented Nov 8, 2016

Confirming issue still present in v0.7.7 and v0.7.9.

This issue is especially inconvenient when using (AWS) credentials generated via STS or federated login which normally expire after only 60mins due to the RDS provisioning and modification taking 40+ mins for instances with large amounts of data.

@jhoblitt
Copy link

jhoblitt commented Mar 8, 2017

This issue appears to still be present under 0.8.8. In the aws console, it shows the parameter group name correctly but followed by (pending-reboot ). A manual reboot applies the parameter group name change.

@estheban
Copy link

estheban commented Jun 6, 2017

Still present in Terraform v0.9.6

@ghost
Copy link

ghost commented Apr 10, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants