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

r/aws_db_parameter_group, r/aws_rds_cluster_parameter_group: Support resetting parameters #5728

Closed
wants to merge 2 commits into from
Closed

Conversation

stefansundin
Copy link
Contributor

@stefansundin stefansundin commented Aug 30, 2018

If you create a parameter group like so:

resource "aws_rds_cluster_parameter_group" "cluster" {
  name        = "test-cluster"
  family      = "aurora-mysql5.7"

  parameter {
    name         = "binlog_format"
    value        = "MIXED"
    apply_method = "pending-reboot"
  }
}

And then uncomment the parameter block and apply again, it doesn't actually do anything. This PR fixes that.

It is sending the parameter value in the reset request, but this doesn't seem to be causing any problems. I inspected a request in the RDS web console, and it also sends the value (and a lot of other stuff).

I tried setting 22 parameters and then resetting them all in one request, and it worked. I was able to re-produce the error of setting more than 20 parameters at the same time.. Is there anywhere else that this limit is documented?

Let me know what you think!! :)

(Relates: #661)

@stefansundin
Copy link
Contributor Author

Oh, and I will write tests for this tomorrow!

@bflad bflad added bug Addresses a defect in current functionality. service/rds Issues and PRs that pertain to the rds service. labels Aug 30, 2018
@stefansundin
Copy link
Contributor Author

I have been trying to add a test that would detect when the code fails to reset the parameter, but I am having issues. So this is with my new code commented out.

I added a new commit with my test code. With that test, and the new code commented out, I expect the test to fail, but it does not.

So my understanding is that in the test steps in TestAccAWSDBParameterGroup_basic, they all use the same parameter group, and it isn't destroyed until after the last test step. So the purpose of my new test step is to try to undo the new parameters that were added in the step before, and then check that collation_connection and collation_server are no longer user defined.

Any help on this would be awesome! Thank you!

Copy link
Contributor

@ryndaniels ryndaniels left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @stefansundin - thanks so much for opening this PR! There's a few minor changes we'd like to see to this, so if you're able to make those changes, we can keep moving forward with getting this merged. Let me know if you have any questions on anything 🙂

@@ -295,6 +295,26 @@ func resourceAwsDbParameterGroupUpdate(d *schema.ResourceData, meta interface{})
}
d.SetPartial("parameter")
}

// Reset parameters that have been removed
parameters, err = expandParameters(os.Difference(ns).List())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm seeing in the ResetDBParameterGroupInput SDK documentation here that there is a documented 20 item max, so it would probably be best to add that logic in here. There's an example of doing this with a for-loop here. 🙂

parameterGroupName := d.Get("name").(string)
resetOpts := rds.ResetDBParameterGroupInput{
DBParameterGroupName: aws.String(parameterGroupName),
Parameters: parameters,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like by default, all parameters are reset so we should add this in to prevent that:

Suggested change
Parameters: parameters,
Parameters: parameters,
ResetAllParameters: aws.Bool(false),

testAccCheckAWSDBParameterGroupExists("aws_db_parameter_group.bar", &v),
testAccCheckAWSDBParameterGroupAttributes(&v, groupName),
testAccCheckAWSDBParameterNotUserDefined("aws_db_parameter_group.bar", "collation_connection"),
testAccCheckAWSDBParameterNotUserDefined("aws_db_parameter_group.bar", "collation_server"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To add some additional checking to this, you could try adding something like:

Suggested change
testAccCheckAWSDBParameterNotUserDefined("aws_db_parameter_group.bar", "collation_server"),
testAccCheckAWSDBParameterNotUserDefined("aws_db_parameter_group.bar", "collation_server"),
testAccCheckNoResourceAttr("aws_db_parameter_group.bar", "parameter.2475805061.value"),

for additional testing to make sure the parameters were reset.

DBParameterGroupName: aws.String(rs.Primary.ID),
Source: aws.String("user"),
}
fmt.Printf("test: %s\n", rs.Primary.ID)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, we'd prefer not to have fmt.Printfs in the code. For potential debug information, a log.Printf could work, but if these were just testing messages, could you go ahead and remove them?

@@ -234,6 +234,26 @@ func resourceAwsRDSClusterParameterGroupUpdate(d *schema.ResourceData, meta inte
}
d.SetPartial("parameter")
}

// Reset parameters that have been removed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you go ahead and add a test for this change as well? Thanks!

@ryndaniels ryndaniels added the waiting-response Maintainers are waiting on response from community or contributor. label Oct 4, 2019
@nathanielks
Copy link
Contributor

@stefansundin Hey there! I was curious if you're still interested in patching this? If not, I might try picking up the torch and finishing it.

@ghost ghost removed the waiting-response Maintainers are waiting on response from community or contributor. label Jan 7, 2020
@stefansundin
Copy link
Contributor Author

@nathanielks Feel free to continue this work.

@ryndaniels ryndaniels self-assigned this Jan 8, 2020
@ryndaniels
Copy link
Contributor

@nathanielks thanks for volunteering to pick this up! I've actually just started working on this myself and have got it just about ready to go, so if there's other stuff that's higher priority for you to work on, that's totally fine and we should be getting this going on our end shortly! 🙂

@nathanielks
Copy link
Contributor

Oh brilliant, thanks @ryndaniels! Carry on, then 😄

@ryndaniels
Copy link
Contributor

(Pulled these commits into another branch (#11540) just to simplify things on our end - thanks for getting this started @stefansundin - I'm going to close this PR to consolidate conversation on the new one! 🙂)

@ryndaniels ryndaniels closed this Jan 9, 2020
@ghost
Copy link

ghost commented Mar 27, 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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Addresses a defect in current functionality. service/rds Issues and PRs that pertain to the rds service.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants