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.

Sign up for GitHub

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

add db workflow documentation #3245

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
+17 −0
Open

add db workflow documentation #3245

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
3ec0b51
add db workflow documentation
Matt-Spence Dec 18, 2024
1f104f0
Update cloning-databases.md
Matt-Spence Dec 23, 2024
9f3fff0
Update cloning-databases.md
Matt-Spence Jan 2, 2025
04e73ce
Merge branch 'main' into XX/documentation-for-cloning-workflow
Matt-Spence Jan 6, 2025
073e405
Merge branch 'main' into XX/documentation-for-cloning-workflow
Matt-Spence Jan 8, 2025
19bdfff
Merge branch 'main' into XX/documentation-for-cloning-workflow
Matt-Spence Jan 8, 2025
f3f1a1f
Update docs/developer/cloning-databases.md
Matt-Spence Jan 14, 2025
791dcc6
Merge branch 'main' into XX/documentation-for-cloning-workflow
Matt-Spence Jan 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions docs/developer/cloning-databases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
# Cloning Databases
The clone-db workflow clones a Source database to a Destination database using cloud.gov's cg-manage-rds tool. This document contains additional information needed to understand how the workflow functions.

## Additional Roles Required
Copy link
Contributor

Choose a reason for hiding this comment

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

@Matt-Spence can you add a section for "how to turn off the db copy in an emergency" with explicit steps for what people should do. If there were a time sensitive issue I think it may take a few mins to process what is being said here and the reverse engineer the commands to turn it off. It would help in a time sensitive situation to just have clear steps to follow for turning it off. I think it would be something like the following
Step 1:
Get the name of the correct service
cf spaces-users cisa-dotgov staging
output should look like:

The space user you want should look like xyz-example

step 2:
Remove the space develeper role by doing the following command
...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can do, but one question: what value does that bring that pushing a change to the workflow itself doesn't?

Copy link
Contributor

Choose a reason for hiding this comment

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

The change to the workflow would require a PR review which immediately slows it down in an emergency as it adds the extra step of putting a PR up, asking someone to approve and waiting for them to see your message( or call) as well as waiting for them to look it over and approve. While you make a good point, this doc should mention "make a PR that deactivates this workflow"as an alternative way to stop the workflow; I do think the list of cf steps would still be better to have in the event that time is really critical.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Gotcha! Added a line at the top noting the other option.

The clone-db workflow functions by temporarily sharing the Destination database with the space of the Source database. This is because cloning databases across spaces is hard. Sharing is done via the `cf share-service` command, but requires that the authenticated user (in this case this will be a user from the Source space) have the `space-developer` role in *both* the Source and Destination spaces. This must be set by someone with permission to edit space roles *before* the workflow runs. The user in question can be found using the `cf space-users [ORG] [SPACE]` command where the SPACE is the Source space, and will appear as a UAA user with a UUID as the name. There is only one such user per space by default (this is a [service account](https://cloud.gov/docs/services/cloud-gov-service-account/) set up by cloud.gov for our Github workflows). This user needs to be provided with the `space-developer` role in the Destination space, which can be accomplished using `cf set-space-role [USER] [ORG] [DESTINATION SPACE] SpaceDeveloper`.