Rackspace schemas

Selective schema discovery and snapshot publication for Rackspace MySQL

Status

Approved architecture. Step 0 implementation and evidence are incomplete. Complete every hard gate in the status record before Step 1 starts.

Context

The existing Rackspace MySQL instance contains dozens of logical databases. Each database can have a different schema.

Rackspace restricts access with a network firewall. The concourse Vercel project has Static IPs in iad1. The status record must record Rackspace allowlist proof for both addresses.

The deployed workflow uses that network path to inspect database definitions. It does not read table data or change Rackspace. Step 0 uses the approved laptop VPN path for local discovery.

Rackspace remains the source of truth for these database definitions. The repository stores imported snapshots for review, history, and future development. The @concourse/rsdb package uses the generated Drizzle schemas for Rackspace data access.

This plan does not change the application release process in the deployment bootstrap.

Decision

Use three Vercel workflows:

An inventory workflow lists the databases that the Rackspace account can inspect.
A refresh workflow snapshots the databases that a system administrator selects.
A verification workflow checks merged snapshots that a system administrator selects.

The refresh workflow processes one database at a time. One selection can contain one database, several databases, or every database in the inventory. All changed databases from one selection enter one pull request.

Use Drizzle Kit for Drizzle schema output. Use MySQL SHOW CREATE statements for database objects that Drizzle does not fully represent.

Use the pull() export from drizzle-kit/cli in the pinned drizzle-kit@1.0.0-rc.4 package. Step 0 must record the exact call and output manifest. A child process is not an approved fallback. If the programmatic API cannot produce the required files, stop and revise this architecture.

Store each complete snapshot in the private, server-only @concourse/rsdb workspace package. The package selects a registered database and returns its generated schema with a configured Drizzle client.

Use Vercel Connect for short-lived GitHub credentials. Do not store a GitHub private key or a personal access token in the Vercel project.

Before deployed implementation, run the permanent local probe through the approved VPN path against QA first and production second. The probe supplies the discovery evidence and generation proof that Step 1 uses.

Goals

Inventory all visible non-system databases.
Let a system administrator select one or more databases.
Regenerate one database without processing unrelated databases.
Process multiple selected databases in a predictable sequence.
Keep complete Drizzle pull output for each selected database.
Keep exact MySQL DDL for all supported database objects.
Provide typed Rackspace data access through @concourse/rsdb.
Permit application data reads and writes without schema changes.
Verify each generated schema against its selected database before publication.
Require human review of raw DDL before GitHub publication.
Let a system administrator verify one or more merged schemas from the deployed application.
Publish all changed selections through one reviewable pull request.
Continue after one selected database fails.
Keep the workflow read-only against Rackspace.

Boundaries and fixed decisions

Rackspace remains the source of truth.
The workflow never changes Rackspace data or schema objects.
The workflow never uses drizzle-kit pull --init.
The workflow never applies a generated migration to Rackspace.
The runtime package never applies migrations or changes Rackspace schema objects.
Runtime applications own their migrations.
Connection verification never returns or changes production rows.
Generated migrations are imported baselines. They are not an incremental migration history.
The workflow does not export rows, MySQL accounts, passwords, or grants.
The workflow does not remove snapshots only because a database disappears from inventory.
The first implementation does not process databases concurrently.
The first implementation does not permit two open schema-refresh pull requests.
A fresh, non-impersonated systemAdmin starts each operation.
Production is the only configured application environment. Step 0 also probes QA locally.
The local probe never changes accounts, grants, schema objects, or application data.
An inventory expires after 24 hours.
A refresh processes selected databases in inventory order.
One database error does not stop later databases.
A failed database keeps its prior snapshot.
A new database enters the registry only after successful review and merge.
One refresh creates at most one pull request.
Raw DDL needs human review before GitHub publication.
A review decision expires after 24 hours. Expiry does not remove a review artifact.
Persistent evidence, Blob artifacts, and Git branches require manual cleanup.
Temporary plaintext cleanup remains automatic after inspection, errors, or handled signals.
Manual cleanup has a seven-day target after a resource becomes eligible.
Refresh and verification share one application-database lease.
The function region is iad1.
Application-database records are the product record and survive Workflow retention. Raw Workflow logs are supporting evidence.

Intentional snapshot removal needs a separate reviewed design change after a database retires. These decisions do not change the selected inventory, selection, sequential processing, or single-pull-request model.

Components

Component	Responsibility
Local probe	Records live QA and production facts through the approved laptop VPN
Administrator page	Starts inventory, accepts a selection, and shows progress
Inventory workflow	Lists visible databases and removes MySQL system databases
Refresh workflow	Revalidates the selection and coordinates database steps
Verification workflow	Checks merged snapshots through the shared verifier
Database step	Produces Drizzle output and exact MySQL DDL for one database
`@concourse/rsdb`	Selects a registered database and supplies its typed Drizzle client
Connection verifier	Verifies TLS, database selection, generated objects, and pool lifecycle
Application database	Stores inventory, operations, leases, reviews, artifacts, and results
Private Blob	Stores encrypted review artifacts until an administrator removes them
Review hook	Pauses a refresh until approval, rejection, or expiry
Publication step	Creates one Git commit and one pull request for all changed selections
Vercel Connect	Supplies a short-lived GitHub app token
Rackspace snapshot user	Supplies read-only metadata access over validated TLS

End-to-end flow

A system administrator starts an inventory operation.
The inventory workflow lists visible databases through the static egress addresses.
The workflow removes MySQL system databases and stores an immutable inventory.
The administrator selects names from an inventory that is not older than 24 hours.
The refresh action creates an operation record and acquires the global lease.
The workflow processes each selected database in sequence.
Each database step creates, scans, and verifies one candidate.
The workflow stores all successful candidates in one encrypted review artifact.
The workflow waits for approval, rejection, or the 24-hour expiry.
After approval, the workflow validates the artifact and current default branch again.
The publication step creates one branch, commit, and pull request when content changed.
The application database stores the final operation and per-database results.
The page polls the application database and shows the safe result.
The page shows artifacts and branches that need manual cleanup.

Documentation map

References

Rackspace schemas

Selective schema discovery and snapshot publication for Rackspace MySQL

Status

Approved architecture. Step 0 implementation and evidence are incomplete. Complete every hard gate in the status record before Step 1 starts.

Context

The existing Rackspace MySQL instance contains dozens of logical databases. Each database can have a different schema.

Rackspace restricts access with a network firewall. The concourse Vercel project has Static IPs in iad1. The status record must record Rackspace allowlist proof for both addresses.

The deployed workflow uses that network path to inspect database definitions. It does not read table data or change Rackspace. Step 0 uses the approved laptop VPN path for local discovery.

This plan does not change the application release process in the deployment bootstrap.

Decision

Use three Vercel workflows:

An inventory workflow lists the databases that the Rackspace account can inspect.
A refresh workflow snapshots the databases that a system administrator selects.
A verification workflow checks merged snapshots that a system administrator selects.

Use Drizzle Kit for Drizzle schema output. Use MySQL SHOW CREATE statements for database objects that Drizzle does not fully represent.

Use Vercel Connect for short-lived GitHub credentials. Do not store a GitHub private key or a personal access token in the Vercel project.

Goals

Inventory all visible non-system databases.
Let a system administrator select one or more databases.
Regenerate one database without processing unrelated databases.
Process multiple selected databases in a predictable sequence.
Keep complete Drizzle pull output for each selected database.
Keep exact MySQL DDL for all supported database objects.
Provide typed Rackspace data access through @concourse/rsdb.
Permit application data reads and writes without schema changes.
Verify each generated schema against its selected database before publication.
Require human review of raw DDL before GitHub publication.
Let a system administrator verify one or more merged schemas from the deployed application.
Publish all changed selections through one reviewable pull request.
Continue after one selected database fails.
Keep the workflow read-only against Rackspace.

Boundaries and fixed decisions

Rackspace remains the source of truth.
The workflow never changes Rackspace data or schema objects.
The workflow never uses drizzle-kit pull --init.
The workflow never applies a generated migration to Rackspace.
The runtime package never applies migrations or changes Rackspace schema objects.
Runtime applications own their migrations.
Connection verification never returns or changes production rows.
Generated migrations are imported baselines. They are not an incremental migration history.
The workflow does not export rows, MySQL accounts, passwords, or grants.
The workflow does not remove snapshots only because a database disappears from inventory.
The first implementation does not process databases concurrently.
The first implementation does not permit two open schema-refresh pull requests.
A fresh, non-impersonated systemAdmin starts each operation.
Production is the only configured application environment. Step 0 also probes QA locally.
The local probe never changes accounts, grants, schema objects, or application data.
An inventory expires after 24 hours.
A refresh processes selected databases in inventory order.
One database error does not stop later databases.
A failed database keeps its prior snapshot.
A new database enters the registry only after successful review and merge.
One refresh creates at most one pull request.
Raw DDL needs human review before GitHub publication.
A review decision expires after 24 hours. Expiry does not remove a review artifact.
Persistent evidence, Blob artifacts, and Git branches require manual cleanup.
Temporary plaintext cleanup remains automatic after inspection, errors, or handled signals.
Manual cleanup has a seven-day target after a resource becomes eligible.
Refresh and verification share one application-database lease.
The function region is iad1.
Application-database records are the product record and survive Workflow retention. Raw Workflow logs are supporting evidence.

Components

Component	Responsibility
Local probe	Records live QA and production facts through the approved laptop VPN
Administrator page	Starts inventory, accepts a selection, and shows progress
Inventory workflow	Lists visible databases and removes MySQL system databases
Refresh workflow	Revalidates the selection and coordinates database steps
Verification workflow	Checks merged snapshots through the shared verifier
Database step	Produces Drizzle output and exact MySQL DDL for one database
`@concourse/rsdb`	Selects a registered database and supplies its typed Drizzle client
Connection verifier	Verifies TLS, database selection, generated objects, and pool lifecycle
Application database	Stores inventory, operations, leases, reviews, artifacts, and results
Private Blob	Stores encrypted review artifacts until an administrator removes them
Review hook	Pauses a refresh until approval, rejection, or expiry
Publication step	Creates one Git commit and one pull request for all changed selections
Vercel Connect	Supplies a short-lived GitHub app token
Rackspace snapshot user	Supplies read-only metadata access over validated TLS

End-to-end flow

A system administrator starts an inventory operation.
The inventory workflow lists visible databases through the static egress addresses.
The workflow removes MySQL system databases and stores an immutable inventory.
The administrator selects names from an inventory that is not older than 24 hours.
The refresh action creates an operation record and acquires the global lease.
The workflow processes each selected database in sequence.
Each database step creates, scans, and verifies one candidate.
The workflow stores all successful candidates in one encrypted review artifact.
The workflow waits for approval, rejection, or the 24-hour expiry.
After approval, the workflow validates the artifact and current default branch again.
The publication step creates one branch, commit, and pull request when content changed.
The application database stores the final operation and per-database results.
The page polls the application database and shows the safe result.
The page shows artifacts and branches that need manual cleanup.

Documentation map

Implementation outline

Step order, delivery rules, and plan maintenance

Status record

Readiness, evidence, and gate tables

Operations

Probe usage, cleanup commands, and environment values

Security

Access, accounts, grants, TLS, and audit

Workflows

Operations, leases, inventory, refresh, and results

Artifacts

Snapshot layout, exact DDL, and review artifacts

Runtime package

@concourse/rsdb contract and verification

Publication

GitHub branches, commits, and pull requests

Acceptance

Verification checklists and final acceptance

Risks

Known risks and operator-recorded values

Implementation steps: Step 0, Step 1, Step 2, Step 3, Step 4, Step 5, Step 6, Step 7, Step 8.

References

Rackspace schemas

Selective schema discovery and snapshot publication for Rackspace MySQL

Status

Approved architecture. Step 0 implementation and evidence are incomplete. Complete every hard gate in the status record before Step 1 starts.

Context

The existing Rackspace MySQL instance contains dozens of logical databases. Each database can have a different schema.

Rackspace restricts access with a network firewall. The concourse Vercel project has Static IPs in iad1. The status record must record Rackspace allowlist proof for both addresses.

The deployed workflow uses that network path to inspect database definitions. It does not read table data or change Rackspace. Step 0 uses the approved laptop VPN path for local discovery.

This plan does not change the application release process in the deployment bootstrap.

Decision

Use three Vercel workflows:

An inventory workflow lists the databases that the Rackspace account can inspect.
A refresh workflow snapshots the databases that a system administrator selects.
A verification workflow checks merged snapshots that a system administrator selects.

Use Drizzle Kit for Drizzle schema output. Use MySQL SHOW CREATE statements for database objects that Drizzle does not fully represent.

Use Vercel Connect for short-lived GitHub credentials. Do not store a GitHub private key or a personal access token in the Vercel project.

Goals

Inventory all visible non-system databases.
Let a system administrator select one or more databases.
Regenerate one database without processing unrelated databases.
Process multiple selected databases in a predictable sequence.
Keep complete Drizzle pull output for each selected database.
Keep exact MySQL DDL for all supported database objects.
Provide typed Rackspace data access through @concourse/rsdb.
Permit application data reads and writes without schema changes.
Verify each generated schema against its selected database before publication.
Require human review of raw DDL before GitHub publication.
Let a system administrator verify one or more merged schemas from the deployed application.
Publish all changed selections through one reviewable pull request.
Continue after one selected database fails.
Keep the workflow read-only against Rackspace.

Boundaries and fixed decisions

Rackspace remains the source of truth.
The workflow never changes Rackspace data or schema objects.
The workflow never uses drizzle-kit pull --init.
The workflow never applies a generated migration to Rackspace.
The runtime package never applies migrations or changes Rackspace schema objects.
Runtime applications own their migrations.
Connection verification never returns or changes production rows.
Generated migrations are imported baselines. They are not an incremental migration history.
The workflow does not export rows, MySQL accounts, passwords, or grants.
The workflow does not remove snapshots only because a database disappears from inventory.
The first implementation does not process databases concurrently.
The first implementation does not permit two open schema-refresh pull requests.
A fresh, non-impersonated systemAdmin starts each operation.
Production is the only configured application environment. Step 0 also probes QA locally.
The local probe never changes accounts, grants, schema objects, or application data.
An inventory expires after 24 hours.
A refresh processes selected databases in inventory order.
One database error does not stop later databases.
A failed database keeps its prior snapshot.
A new database enters the registry only after successful review and merge.
One refresh creates at most one pull request.
Raw DDL needs human review before GitHub publication.
A review decision expires after 24 hours. Expiry does not remove a review artifact.
Persistent evidence, Blob artifacts, and Git branches require manual cleanup.
Temporary plaintext cleanup remains automatic after inspection, errors, or handled signals.
Manual cleanup has a seven-day target after a resource becomes eligible.
Refresh and verification share one application-database lease.
The function region is iad1.
Application-database records are the product record and survive Workflow retention. Raw Workflow logs are supporting evidence.

Components

Component	Responsibility
Local probe	Records live QA and production facts through the approved laptop VPN
Administrator page	Starts inventory, accepts a selection, and shows progress
Inventory workflow	Lists visible databases and removes MySQL system databases
Refresh workflow	Revalidates the selection and coordinates database steps
Verification workflow	Checks merged snapshots through the shared verifier
Database step	Produces Drizzle output and exact MySQL DDL for one database
`@concourse/rsdb`	Selects a registered database and supplies its typed Drizzle client
Connection verifier	Verifies TLS, database selection, generated objects, and pool lifecycle
Application database	Stores inventory, operations, leases, reviews, artifacts, and results
Private Blob	Stores encrypted review artifacts until an administrator removes them
Review hook	Pauses a refresh until approval, rejection, or expiry
Publication step	Creates one Git commit and one pull request for all changed selections
Vercel Connect	Supplies a short-lived GitHub app token
Rackspace snapshot user	Supplies read-only metadata access over validated TLS

End-to-end flow

A system administrator starts an inventory operation.
The inventory workflow lists visible databases through the static egress addresses.
The workflow removes MySQL system databases and stores an immutable inventory.
The administrator selects names from an inventory that is not older than 24 hours.
The refresh action creates an operation record and acquires the global lease.
The workflow processes each selected database in sequence.
Each database step creates, scans, and verifies one candidate.
The workflow stores all successful candidates in one encrypted review artifact.
The workflow waits for approval, rejection, or the 24-hour expiry.
After approval, the workflow validates the artifact and current default branch again.
The publication step creates one branch, commit, and pull request when content changed.
The application database stores the final operation and per-database results.
The page polls the application database and shows the safe result.
The page shows artifacts and branches that need manual cleanup.

Documentation map

Implementation outline

Step order, delivery rules, and plan maintenance

Status record

Readiness, evidence, and gate tables

Operations

Probe usage, cleanup commands, and environment values

Security

Access, accounts, grants, TLS, and audit

Workflows

Operations, leases, inventory, refresh, and results

Artifacts

Snapshot layout, exact DDL, and review artifacts

Runtime package

@concourse/rsdb contract and verification

Publication

GitHub branches, commits, and pull requests

Acceptance

Verification checklists and final acceptance

Risks

Known risks and operator-recorded values

Implementation steps: Step 0, Step 1, Step 2, Step 3, Step 4, Step 5, Step 6, Step 7, Step 8.

References

Rackspace schemas

Selective schema discovery and snapshot publication for Rackspace MySQL

Status

Approved architecture. Step 0 implementation and evidence are incomplete. Complete every hard gate in the status record before Step 1 starts.

Context

The existing Rackspace MySQL instance contains dozens of logical databases. Each database can have a different schema.

Rackspace restricts access with a network firewall. The concourse Vercel project has Static IPs in iad1. The status record must record Rackspace allowlist proof for both addresses.

The deployed workflow uses that network path to inspect database definitions. It does not read table data or change Rackspace. Step 0 uses the approved laptop VPN path for local discovery.

This plan does not change the application release process in the deployment bootstrap.

Decision

Use three Vercel workflows:

An inventory workflow lists the databases that the Rackspace account can inspect.
A refresh workflow snapshots the databases that a system administrator selects.
A verification workflow checks merged snapshots that a system administrator selects.

Use Drizzle Kit for Drizzle schema output. Use MySQL SHOW CREATE statements for database objects that Drizzle does not fully represent.

Use Vercel Connect for short-lived GitHub credentials. Do not store a GitHub private key or a personal access token in the Vercel project.

Goals

Inventory all visible non-system databases.
Let a system administrator select one or more databases.
Regenerate one database without processing unrelated databases.
Process multiple selected databases in a predictable sequence.
Keep complete Drizzle pull output for each selected database.
Keep exact MySQL DDL for all supported database objects.
Provide typed Rackspace data access through @concourse/rsdb.
Permit application data reads and writes without schema changes.
Verify each generated schema against its selected database before publication.
Require human review of raw DDL before GitHub publication.
Let a system administrator verify one or more merged schemas from the deployed application.
Publish all changed selections through one reviewable pull request.
Continue after one selected database fails.
Keep the workflow read-only against Rackspace.

Boundaries and fixed decisions

Rackspace remains the source of truth.
The workflow never changes Rackspace data or schema objects.
The workflow never uses drizzle-kit pull --init.
The workflow never applies a generated migration to Rackspace.
The runtime package never applies migrations or changes Rackspace schema objects.
Runtime applications own their migrations.
Connection verification never returns or changes production rows.
Generated migrations are imported baselines. They are not an incremental migration history.
The workflow does not export rows, MySQL accounts, passwords, or grants.
The workflow does not remove snapshots only because a database disappears from inventory.
The first implementation does not process databases concurrently.
The first implementation does not permit two open schema-refresh pull requests.
A fresh, non-impersonated systemAdmin starts each operation.
Production is the only configured application environment. Step 0 also probes QA locally.
The local probe never changes accounts, grants, schema objects, or application data.
An inventory expires after 24 hours.
A refresh processes selected databases in inventory order.
One database error does not stop later databases.
A failed database keeps its prior snapshot.
A new database enters the registry only after successful review and merge.
One refresh creates at most one pull request.
Raw DDL needs human review before GitHub publication.
A review decision expires after 24 hours. Expiry does not remove a review artifact.
Persistent evidence, Blob artifacts, and Git branches require manual cleanup.
Temporary plaintext cleanup remains automatic after inspection, errors, or handled signals.
Manual cleanup has a seven-day target after a resource becomes eligible.
Refresh and verification share one application-database lease.
The function region is iad1.
Application-database records are the product record and survive Workflow retention. Raw Workflow logs are supporting evidence.

Components

Component	Responsibility
Local probe	Records live QA and production facts through the approved laptop VPN
Administrator page	Starts inventory, accepts a selection, and shows progress
Inventory workflow	Lists visible databases and removes MySQL system databases
Refresh workflow	Revalidates the selection and coordinates database steps
Verification workflow	Checks merged snapshots through the shared verifier
Database step	Produces Drizzle output and exact MySQL DDL for one database
`@concourse/rsdb`	Selects a registered database and supplies its typed Drizzle client
Connection verifier	Verifies TLS, database selection, generated objects, and pool lifecycle
Application database	Stores inventory, operations, leases, reviews, artifacts, and results
Private Blob	Stores encrypted review artifacts until an administrator removes them
Review hook	Pauses a refresh until approval, rejection, or expiry
Publication step	Creates one Git commit and one pull request for all changed selections
Vercel Connect	Supplies a short-lived GitHub app token
Rackspace snapshot user	Supplies read-only metadata access over validated TLS

End-to-end flow

A system administrator starts an inventory operation.
The inventory workflow lists visible databases through the static egress addresses.
The workflow removes MySQL system databases and stores an immutable inventory.
The administrator selects names from an inventory that is not older than 24 hours.
The refresh action creates an operation record and acquires the global lease.
The workflow processes each selected database in sequence.
Each database step creates, scans, and verifies one candidate.
The workflow stores all successful candidates in one encrypted review artifact.
The workflow waits for approval, rejection, or the 24-hour expiry.
After approval, the workflow validates the artifact and current default branch again.
The publication step creates one branch, commit, and pull request when content changed.
The application database stores the final operation and per-database results.
The page polls the application database and shows the safe result.
The page shows artifacts and branches that need manual cleanup.

Documentation map

Implementation outline

Step order, delivery rules, and plan maintenance

Status record

Readiness, evidence, and gate tables

Operations

Probe usage, cleanup commands, and environment values

Security

Access, accounts, grants, TLS, and audit

Workflows

Operations, leases, inventory, refresh, and results

Artifacts

Snapshot layout, exact DDL, and review artifacts

Runtime package

@concourse/rsdb contract and verification

Publication

GitHub branches, commits, and pull requests

Acceptance

Verification checklists and final acceptance

Risks

Known risks and operator-recorded values

Implementation steps: Step 0, Step 1, Step 2, Step 3, Step 4, Step 5, Step 6, Step 7, Step 8.

Search documentation

Search documentation

Search documentation

Status

Context

Decision

Goals

Boundaries and fixed decisions

Components

End-to-end flow

Documentation map

Implementation outline

Status record

Operations

Security

Workflows

Artifacts

Runtime package

Publication

Acceptance

Risks

References

Search documentation

Status

Context

Decision

Goals

Boundaries and fixed decisions

Components

End-to-end flow

Documentation map

Implementation outline

Status record

Operations

Security

Workflows

Artifacts

Runtime package

Publication

Acceptance

Risks

References

Search documentation

Search documentation

Status

Context

Decision

Goals

Boundaries and fixed decisions

Components

End-to-end flow

Documentation map

Implementation outline

Status record

Operations

Security

Workflows

Artifacts

Runtime package

Publication

Acceptance

Risks

References

Search documentation

Status

Context

Decision

Goals

Boundaries and fixed decisions

Components

End-to-end flow

Documentation map

Implementation outline

Status record

Operations

Security

Workflows

Artifacts

Runtime package

Publication