The AQS 2.0 services use external testing environments to represent the production data stores during local development and local testing, per T288160: Development and test environments for AQS 2.0 Cassandra services. And maybe soon during CI, per T330223: AQS 2.0: refactor Cassandra testing env for use in CI.

The services created thus far (as of 2023-02-24) all use the Cassandra-based testing env, which provides a small subset of our production Cassandra data (there is no PII involved with this already-publicly-available data, and therefore not security or privacy concerns). We pulled this data fairly early in the AQS 2.0 project, and have rarely needed to update it.

However, it is not reasonable to expect that we will never need to update the data in this env. So we should, before it becomes a blocker document the procedure for doing this. And if helper scripts are (or can be) used to extract this data, we should document those as well, and add them to the testing env repo.

This env currently lives here, but is expected to move as part of T330223. But that move (and other changes that may occur as part of that task) is unlikely to have major impacts on how production data is extracted.

Completion criteria:

• instructions for extracting data are documented within the repo
• script or scripts to pull data (if any) is/are committed to the repo
• instructions for executing the script(s) (if any) are documented within the repo