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

Make VPC database resources to be conditionally added only if there is a database needed in the network #590

Merged
merged 4 commits into from
May 2, 2024

Conversation

rocketnova
Copy link
Contributor

@rocketnova rocketnova commented Apr 26, 2024

Ticket

N/A

Changes

What was added, updated, or removed in this PR.

  • Set database subnets and subnet group to be conditionally added only if there is a database specified in the network

Context for reviewers

Testing instructions, background context, more in-depth details of the implementation, and anything else you'd like to call out or ask reviewers.

Right now, the first time you configure the network and run make infra-update-network NETWORK_NAME=<NETWORK_NAME>, the database subnets and subnet group are created even if there are no databases specified in the network.

This change makes creating those resources conditional based on whether or not there databases are needed.

I think it's better to make this conditional to reduce the number of unnecessary resources created. In general, unnecessary resources add additional cost and management overhead (i.e. it was confusing to me to see database subnets being created for an application that had no database).

Testing

Provide evidence that the code works as expected. Explain what was done for testing and the results of the test plan. Include screenshots, GIF demos, shell commands or output to help show the changes working as expected. ProTip: you can drag and drop or paste images into this textbox.

Testing performed by deploying this branch to my local version of https://github.com/navapbc/platform-test and then deploying necessary resources (account, network) to my AWS account. This screenshot shows:

  • on the top left, has_database is set to false in /infra/app/app-config/main.tf
  • on the bottom left, the changes in this PR
  • on the right, the deployed dev network which does not have any database VPC endpoints

CleanShot 2024-05-01 at 16 16 40@2x

Copy link

@srvanderjagt srvanderjagt left a comment

Choose a reason for hiding this comment

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

This looks good!

Copy link
Contributor

@lorenyu lorenyu left a comment

Choose a reason for hiding this comment

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

left some nits. also, i didn't see any evidence of testing in the PR, which i'd ideally like to see before approving

Comment on lines 25 to 26
database_subnet_tags = var.has_database ? { subnet_type = "database" } : {}
database_subnet_group_name = var.has_database ? var.database_subnet_group_name : ""
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I believe we don't actually need the conditionals here:

  1. the tags only apply to created db subnets so if we don't create db subnets then the tags don't apply
  2. similarly the subnet group name doesn't do anything if create database subnet group is false

Copy link

@srvanderjagt srvanderjagt Apr 30, 2024

Choose a reason for hiding this comment

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

While they aren't strictly needed, I do prefer that the usage is explicit, rather than implied. Whenever I am tracing broken code things can become confusing if people are setting what appear to be "dead" variables. Alternatively a comment may be helpful?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd be fine with a comment. In my opinion dead code causes more issues than dead variables.

Choose a reason for hiding this comment

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

Note: This is my personal github. I'll get signed into my usual one and make sure I'm on the right account in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@lorenyu Good catch. I've pushed a change that removes the unnecessary conditionals and adds some more commenting. The comments were a little unwieldy, so I re-organized a little to group related items together.

infra/modules/network/main.tf Outdated Show resolved Hide resolved
@rocketnova
Copy link
Contributor Author

left some nits. also, i didn't see any evidence of testing in the PR, which i'd ideally like to see before approving

Adding now and will re-ping you when I'm ready for re-review. Thanks!

@rocketnova rocketnova requested a review from lorenyu May 1, 2024 23:32
Copy link
Contributor

@lorenyu lorenyu left a comment

Choose a reason for hiding this comment

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

LGTM. Sorry for the delayed review.

Rollout note:
One thing to remember to do after merging, is that on platform-test-nextjs you'll want to run terraform apply in the network layer, since the network layer doesn't get auto-applied as part of CD. I imagine apply would end up removing the subnets and subnet group.

@rocketnova
Copy link
Contributor Author

Rollout note: One thing to remember to do after merging, is that on platform-test-nextjs you'll want to run terraform apply in the network layer, since the network layer doesn't get auto-applied as part of CD. I imagine apply would end up removing the subnets and subnet group.

Thank you for the tip! I would have missed that.

@rocketnova rocketnova merged commit d42963d into main May 2, 2024
9 checks passed
@rocketnova rocketnova deleted the rocket/optional-db-network-resources branch May 2, 2024 22:07
@rocketnova
Copy link
Contributor Author

Rollout note: One thing to remember to do after merging, is that on platform-test-nextjs you'll want to run terraform apply in the network layer, since the network layer doesn't get auto-applied as part of CD. I imagine apply would end up removing the subnets and subnet group.

Thank you for the tip! I would have missed that.

Following up to say that this is complete!

@rocketnova rocketnova mentioned this pull request May 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants