From 9f3fff03fdfaac009377c522f81eb8eb1f0d44c1 Mon Sep 17 00:00:00 2001 From: Matt-Spence Date: Thu, 2 Jan 2025 12:45:28 -0600 Subject: [PATCH] Update cloning-databases.md --- docs/developer/cloning-databases.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/developer/cloning-databases.md b/docs/developer/cloning-databases.md index cd4b2e9c1..4dcb5f52d 100644 --- a/docs/developer/cloning-databases.md +++ b/docs/developer/cloning-databases.md @@ -5,6 +5,8 @@ The clone-db workflow clones a Source database to a Destination database using c 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`. ## Turning Off DB Cloning Fast (For Emergencies or other Scenarios) +Note: In less urgent situations it may be better to make a PR removing the scheduled workflow trigger. + Step 1: Get the name of the correct service using `cf spaces-users cisa-dotgov stable`. There should only be one user with a name that is a UUID, that is the one you want.