DC-250: Provision rotation app-user across all target databases - #495
Merged
Conversation
Plan output — dev-dcPlan output — dev-co |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
🔗 Jira ticket
DC-250
✍️ Description
The DC dev environment's API container has been stuck in a restart loop. Root cause: the credential-rotation Lambda's set_secret/test_secret steps only ever provisioned the app user (
appuser/appuser_clone) in theSebtPortaldatabase. DC also points the DC-connector plugin at a second database on the same RDS instance,DcSource, using the same rotating credentials — but nothing ever created a database user for the app login there. Once appuser_clone became the active credential, the API could reach SebtPortal fine but every DcSource connection (including the dc-sql-connectivity health check) failed with SQL error 4060 ("Cannot open database... login failed"), keeping ECS in a permanent restart loop.This PR:
additional_db_namesto thesebt_databasemodule and threads it fromsebt_applicationas [var.dc_source_db_name] — empty for CO, ["DcSource"] for DC, so the Lambda only touches databases that actually exist for a given state.rotate_db_credentials.pysoset_secret/test_secretloop over every target database (primary + ADDITIONAL_DB_NAMES) instead of just the primary one.ecs_service_namein sebt_application/main.tf, which was aliasing module.api.cluster_name — currently correct only because the CfA fargate module happens to name the ECS cluster and service identically (not because that's a documented contract. Now derived explicitly via a new local.api_ecs_service_name, so a future upstream naming change can't silently break the Lambda's ecs:UpdateService call.DB_ROTATION_ECS_RESTART_FAILED) when that ECS restart call fails, so it can be wired to a Datadog log monitor instead of failing silently.✅ Completion tasks