Set max_allocated_storage var and switch to updated Terraform db module #1312
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KlaasH
force-pushed
the
feature/kjh/update-postgres-terraform-module
branch
from
b08a596
to
25d9f42
Compare
aaronxsu
approved these changes
Jun 23, 2023
| @@ -75,14 +75,17 @@ resource "aws_db_parameter_group" "default" { | |||
| } | |||
|
|
|||
| module "database" { | |||
| source = "github.com/azavea/terraform-aws-postgresql-rds?ref=3.0.0" | |||
| # TODO: go back to github.com/azavea/terraform-aws-postgresql-rds once it's updated | |||
| # (see https://github.com/azavea/terraform-aws-postgresql-rds/pull/48) | |||
There was a problem hiding this comment.
Thanks for leaving a commend here. I'd suggest we also create an issue in this repo so that we use that one to update the source once the PR is merged in the upstream.
There was a problem hiding this comment.
Good point. I made #1316.
| @@ -58,6 +58,11 @@ variable "rds_allocated_storage" { | |||
| type = string | |||
| } | |||
|
|
|||
| variable "rds_max_allocated_storage" { | |||
There was a problem hiding this comment.
I'd assume the tfvars in S3 is already updated- right?
There was a problem hiding this comment.
I haven't updated it yet, but I will before I push the button to deploy to production. I'm going to watch the staging build after I merge and double-check the production vars against the staging ones to make sure they're how we want them.
There was a problem hiding this comment.
Sounds like a plan to me 👍🏼
KlaasH
force-pushed
the
feature/kjh/update-postgres-terraform-module
branch
from
25d9f42
to
d9437b1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
In the course of dealing with issue #1307, I switched the database to using storage auto-scaling (and also to the
gp3storage type). But the Terraform module we're using for the database config hasn't been updated in a while and doesn't support auto-scaling. So I wasn't able to update the Terraform config then to match the changes I'd made in the console, but I left it at that. Turns out, having the deployed state differ from the Terraform config in a way that the config can't even represent is a bad plan, and it bit us, in the form of an attempt to run the Release action crashing and leaving the infrastructure in a somewhat broken in-between state.So we need to update the Terraform config for the database to match how it is in production, that that's what this does. It switches to a fork of the module that has the
max_allocated_storageparameter added.I opened a PR on the module repo, but I'm not sure what the maintenance situation is for those modules these days, so I think it makes sense to just use the branch on my fork for now.
Checklist
CHANGELOG.mdand grouped with similar changes, if possibleDemo
I made the same manual change to the staging database that I had made to production (changing to gp3 and turning on auto-scaling) then pushed a test branch to run a test deploy to staging. Per the logs, it noticed that the database had been changed outside of Terraform, but didn't find any changes that needed to be applied to it.
Testing Instructions
With this branch checked out, run the Terraform container:
(that's the currently-deployed git commit, to avoid requiring that the app services get updated)
Inside that container, run
./scripts/infra plan. It will show some changes—I think that's a combination of the partial apply from the failed deploy and possibly some drift on the AWS side—but it shouldn't show any changes required forresource "aws_db_instance" "postgresql"(whereas if you check outdevelopand run it again, it will).