[AN-524] Switch docs to reference Batch instead of Papi (#7816)

lucymcnatt · web-flow · commit 739ee52351ef · 2025-10-07T12:12:10.000-04:00
diff --git a/centaur/src/main/resources/upgradeNewWorkflowsTestCases/cromwell_restart.test b/centaur/src/main/resources/upgradeNewWorkflowsTestCases/cromwell_restart.test
diff --git a/centaur/src/main/resources/upgradeNewWorkflowsTestCases/cromwell_restart/cromwell_restart.options b/centaur/src/main/resources/upgradeNewWorkflowsTestCases/cromwell_restart/cromwell_restart.options
diff --git a/centaur/src/main/resources/upgradeNewWorkflowsTestCases/cromwell_restart/cromwell_restart.wdl b/centaur/src/main/resources/upgradeNewWorkflowsTestCases/cromwell_restart/cromwell_restart.wdl
diff --git a/docs/RuntimeAttributes.md b/docs/RuntimeAttributes.md
@@ -64,7 +64,6 @@ There are a number of additional runtime attributes that apply to the Google Clo
 - [noAddress](#noaddress)
 - [gpuCount, gpuType, and nvidiaDriverVersion](#gpucount-gputype-and-nvidiadriverversion)
 - [cpuPlatform](#cpuplatform)
-- [useDockerImageCache](#usedockerimagecache)
 
 
 ### AWS Specific Attributes
@@ -445,12 +444,6 @@ The following CPU platforms are currently supported by the Google Cloud backend:
 - `Intel Sandy Bridge`
 - `AMD Rome`
 
-### 'useDockerImageCache'
-
-This option is specific to the Google Cloud backend, moreover it is only supported by Google Life Sciences API starting from version v2 beta.
-In order to use this feature Cromwell has to have PAPI v2 backend configured with this feature enabled.  
-More information about this feature and it's configuration can be found [in the Google backend section of documentation](backends/Google.md).
-
 ### `awsBatchRetryAttempts`
 
 *Default: _0_*
diff --git a/docs/backends/Backends.md b/docs/backends/Backends.md
@@ -9,7 +9,7 @@ Cromwell distribution:
     * Run jobs as subprocesses or via a dispatcher.
     * Supports launching in Docker containers.
     * Use `bash`, `qsub`, and `bsub` to run scripts.
-* **[Google Cloud](Google)** 
+* **[Google Cloud](GCPBatch)** 
     * Launch jobs on Google Compute Engine through Google Batch.
 * **[GA4GH TES](TES)** 
     * Launch jobs on servers that support the GA4GH Task Execution Schema (TES).
diff --git a/docs/backends/Google.md b/docs/backends/Google.md
diff --git a/docs/backends/HPC.md b/docs/backends/HPC.md
@@ -115,7 +115,7 @@ during execution as `/mnt/three` was not present inside the running container.
 ### Additional FileSystems
 
 HPC backends (as well as the Local backend) can be configured to be able to interact with other type of filesystems, where the input files can be located for example.
-Currently the only other filesystem supported is Google Cloud Storage (GCS). See the [Google section](Google) of the documentation for information on how to configure GCS in Cromwell.
+Currently the only other filesystem supported is Google Cloud Storage (GCS). See the [Google section](GCPBatch) of the documentation for information on how to configure GCS in Cromwell.
 Once you have a google authentication configured, you can simply add a `gcs` stanza in your configuration file to enable GCS:
 
 ```
diff --git a/docs/cromwell_features/CallCaching.md b/docs/cromwell_features/CallCaching.md
@@ -112,18 +112,18 @@ allows Cromwell to record which file path prefixes were involved in cache result
 If Cromwell sees that the file paths for a candidate cache hit have a blacklisted prefix, Cromwell will quickly 
 fail the copy attempt without doing any potentially expensive I/O.
 
-Path prefix blacklisting could be supported by any backend type though it is currently implemented only for Google
-(PAPI) backends. For Google backends the GCS bucket is considered the prefix for blacklisting purposes.
+Path prefix blacklisting could be supported by any backend type though it is currently implemented only for Google backends. 
+For Google backends the GCS bucket is considered the prefix for blacklisting purposes.
 
 
 ***Call cache whitelisting***
  
 In a multi-user environment where access to job outputs may be restricted among different users, it can be useful to limit
 cache hits to those that are more likely to actually be readable for cache hit copies.
-Cromwell now supports a `call_cache_hit_path_prefixes` workflow option for this purpose. This is particularly useful in the PAPI backend where the workflow
-root can be specified in workflow options via `jes_gcs_root`. The value of `call_cache_hit_path_prefixes` should be an array of strings representing  
-prefixes that call cache hit output files should have in order to be considered as a cache hit. Using PAPI as an example and assuming Alice and Bob have
-made their data accessible to each other, Alice could submit a workflow with these options:
+Cromwell now supports a `call_cache_hit_path_prefixes` workflow option for this purpose. This is particularly useful in the GCP Batch backend where the workflow
+root can be specified in workflow options via `gcp_batch_gcs_root`. The value of `call_cache_hit_path_prefixes` should be an array of strings representing  
+prefixes that call cache hit output files should have in order to be considered as a cache hit. Assuming Alice and Bob have made their data accessible to each other, 
+Alice could submit a workflow with these options:
 
 ```
 {
@@ -133,10 +133,10 @@ made their data accessible to each other, Alice could submit a workflow with the
 
 With these workflow options Cromwell would only look for cache hits for Alice's jobs in Alice's or Bob's buckets.
 
-As a further optimization the PAPI backend has the concept of "this" bucket on a per-workflow basis, where "this" bucket is
+As a further optimization the Batch backend has the concept of "this" bucket on a per-workflow basis, where "this" bucket is
 the bucket that contains the current workflow root.
 If `call_cache_hit_path_prefixes` is specified in 
-workflow options on the PAPI backend, Cromwell will automatically prepend "this" bucket to the call cache hit path prefixes to search.
+workflow options on the Batch backend, Cromwell will automatically prepend "this" bucket to the call cache hit path prefixes to search.
 For example, if Charles specified the same workflow options as in the example above and his workflow root was under `gs://charles_bucket`,
 Cromwell would search cache hits in all of the `gs://alice_bucket`, `gs://bob_bucket` and `gs://charles_bucket` buckets without having to specify
 `gs://charles_bucket` bucket explicitly in `call_cache_hit_path_prefixes`.
diff --git a/docs/cromwell_features/HogFactors.md b/docs/cromwell_features/HogFactors.md
@@ -68,7 +68,7 @@ Additionally, you can override system-level hog-factor on a backend level, by se
 ```conf
 backend {
   providers {
-    PAPIv2 {
+    GCPBatch {
       config {
         hog-factor: 2
       }
@@ -145,13 +145,13 @@ jobA1, jobB1, jobC1, jobD1, jobA2, jobB2, jobD2, jobA3, ..., jobA1000000
 
 ##### An administrator sets up a Cromwell server
 
-- A Cromwell administrator sets the overall maximum concurrent job limit to 100,000 PAPIv2 jobs.
+- A Cromwell administrator sets the overall maximum concurrent job limit to 100,000 GCP Batch jobs.
 - The administrator also sets the hog factor to be 25.
-- Cromwell will therefore calculate a per-hog-group concurrent job limit of 4,000 PAPIv2 jobs.
+- Cromwell will therefore calculate a per-hog-group concurrent job limit of 4,000 GCP Batch jobs.
 
 ##### Our first hog group hits its limit
 
-- 100 workflows are running in hog group "A" and between them have generated 20,000 jobs for PAPIv2. 
+- 100 workflows are running in hog group "A" and between them have generated 20,000 jobs for GCP Batch. 
     + Cromwell initially starts 4,000 jobs.
     + Cromwell then starts the remaining 16,000 new jobs as existing jobs from this group finish.
     + New workflows in this group will not be able to start jobs either
@@ -160,7 +160,7 @@ jobA1, jobB1, jobC1, jobD1, jobA2, jobB2, jobD2, jobA3, ..., jobA1000000
 
 ##### Another hog group appears
 
-- Now hog group B submits 1,000 workflows and between them they generate 200,000 jobs for PAPIv2.
+- Now hog group B submits 1,000 workflows and between them they generate 200,000 jobs for GCP Batch.
 - Even though 16,000 of group A's jobs are still queued, Cromwell starts 4,000 of group B's jobs immediately,
 - The remaining 196,000 of group B's jobs are queued up waiting for group B's existing jobs to complete.
 
diff --git a/docs/developers/Centaur.md b/docs/developers/Centaur.md
@@ -124,28 +124,23 @@ Note: To exclude a specific test from a test suite, find the `.sh` file that run
 
 ## Upgrade / Horicromtal / etc.
 
-| CI Test Type                  | Cromwell Config                                                  | Centaur Config                                         |
-|-------------------------------|------------------------------------------------------------------|--------------------------------------------------------|
-| Engine Upgrade                | `(backend)_application.conf`                                     | `centaur_application.conf`*                            |
-| Horicromtal                   | `papi_[v2beta or v2alpha1]_horicromtal_application.conf`**       | `centaur_application_`<br>`horicromtal.conf`           |
-| Horicromtal<br>Engine Upgrade | `papi_v2beta_application.conf`**                                 | `centaur_application_`<br>`horicromtal_no_assert.conf` |
-| PAPI Upgrade                  | `papi_v1_v2alpha1_upgrade_application.conf`**                    | `centaur_application.conf`*                            |
-| Papi Upgrade<br>New Workflows | `(backend)_application.conf`                                     | `centaur_application.conf`*                            |
-| WDL Upgrade                   | `(backend)_application.conf`                                     | `centaur_application.conf`*                            |
-| (other)                       | `(backend)_application.conf`                                     | `centaur_application.conf`*                            |
+| CI Test Type                   | Cromwell Config                            | Centaur Config                                         |
+|--------------------------------|--------------------------------------------|--------------------------------------------------------|
+| Engine Upgrade                 | `(backend)_application.conf`               | `centaur_application.conf`*                            |
+| Horicromtal                    | `(backend)_horicromtal_application.conf`** | `centaur_application_`<br>`horicromtal.conf`           |
+| Horicromtal<br>Engine Upgrade | `(backend))_application.conf`**            | `centaur_application_`<br>`horicromtal_no_assert.conf` |
+| WDL Upgrade                    | `(backend)_application.conf`               | `centaur_application.conf`*                            |
+| (other)                        | `(backend)_application.conf`               | `centaur_application.conf`*                            |
 
 | CI Test Type                  | ScalaTest Spec              | Test Directory                      |
 |-------------------------------|-----------------------------|-------------------------------------|
 | Engine Upgrade                | `EngineUpgradeTestCaseSpec` | `engineUpgradeTestCases`            |
 | Horicromtal                   | `CentaurTestSuite`          | `standardTestCases`***              |
 | Horicromtal<br>Engine Upgrade | `EngineUpgradeTestCaseSpec` | `engineUpgradeTestCases`***         |
-| PAPI Upgrade                  | `PapiUpgradeTestCaseSpec`   | `papiUpgradeTestCases`              |
-| PAPI Upgrade<br>New Workflows | `CentaurTestSuite`          | `papiUpgradeNewWorkflowsTestCases`  |
 | (other)                       | `CentaurTestSuite`          | `standardTestCases`                 |
 
 <small>
-\* Centaur Config always uses `centaur_application.conf` except when overridden with `papi_v2alpha1_centaur_application.conf`
-or `papi_v2beta_centaur_application.conf`
+\* Centaur Config always uses `centaur_application.conf` except when overridden with `centaur_application_horicromtal.conf`
   ([48 preview link](https://github.com/broadinstitute/cromwell/blob/a7d0601/src/ci/bin/test.inc.sh#L455-L457))  
 \*\* Cromwell Config overrides
   ([47 link](https://github.com/broadinstitute/cromwell/blob/47/src/ci/bin/test.inc.sh#L213-L221))  
@@ -158,24 +153,23 @@ or `papi_v2beta_centaur_application.conf`
     1. db-mstr: started first
     2. sum-back: runs summarizer
     3. front-back: exposes HTTP
-- Horicromtal Engine Upgrade: Combination of Horicromtal and Engine Upgrade
-- PAPI Upgrade: Tests run with an older version of Papi and upon restart use a newer version of Papi
-- PAPI Upgrade New Workflows: Test definition [does not run any tests](https://travis-ci.org/broadinstitute/cromwell/jobs/475378412)
+- Horicromtal Engine Upgrade: Combination of Horicromtal and Engine Upgrade
 - WDL Upgrade: Upgrades WDL from draft-2 to 1.0 before testing
 - (other): Runs `*.test` files listing the configured backend names
 
 ## RDBMS
 
-| Backend | MySQL  | PostgreSQL  | MariaDB  |
-|---------|:------:|:-----------:|:--------:|
-| AWS     |   ✅   |             |          |
-| Local   |   ✅   |      ✅     |          |
-| PAPI V2 |   ✅   |             |    ⭕    |
-| SLURM   |   ✅   |             |          |
-| TES     |   ✅   |             |          |
+| Backend   | MySQL  | PostgreSQL  | MariaDB  |
+|-----------|:------:|:-----------:|:--------:|
+| AWS       |   ✅  ⭕ |             |          |
+| GCP Batch |   ✅ ⭕  |             |          |
+| Local     |   ✅   |      ✅     |          |
+| SLURM     |   ✅   |             |          |
+| TES       |   ✅   |             |          |
 
 <small>
-⭕ Tests Horicromtal Engine Upgrade versus standard Centaur suite
+⭕ Tests Horicromtal Engine versus standard Centaur suite
 </small>
 
-All backends run against MySQL. The Local backend also test PostgreSQL, allowing contributors ensure WDLs work with PostgreSQL. MariaDB is tested on a specialized upgrade, where the MySQL connector client is used first, and the MariaDB client is used after restart.
+All backends run against MySQL. The Local backend also test PostgreSQL, allowing contributors ensure WDLs work with PostgreSQL. 
+MariaDB is tested on a specialized upgrade, where the MySQL connector client is used first, and the MariaDB client is used after restart.
diff --git a/docs/developers/Running.md b/docs/developers/Running.md
@@ -15,4 +15,4 @@ Example for batch:
 Upon startup, the Cromwell swagger will be available at `http://localhost:8000`.
 (You can change the port and other configurations by following [these instructions](../Configuring.md)
 
-**Note**: To verify that workflows are being submitted to the correct backend, look for logs  with `Call-to-Backend assignments` and check that the tasks are being directed to `-> GCPBATCH` or `-> PAPI` etc.
+**Note**: To verify that workflows are being submitted to the correct backend, look for logs  with `Call-to-Backend assignments` and check that the tasks are being directed to `-> GCPBATCH`.
diff --git a/docs/developers/bitesize/jobRetryLogic/jobRetryLogic.md b/docs/developers/bitesize/jobRetryLogic/jobRetryLogic.md
@@ -9,7 +9,7 @@
 * Job may have attributes which are being stored in the `JOB_KEY_VALUE_ENTRY` table in the database, identified by a 
 `ScopedKey`, which comprises workflow id, call fully qualified name, job index, job attempt number, and attribute name.
 * There are 2 types of retries:
-  * backend-specific retries (e.g., VM preemption in PAPI)
+  * backend-specific retries (e.g., VM preemption in GCP Batch)
   * general retries 
 * Backend-specific and general retries have separate retry counters, which are being stored in `JOB_KEY_VALUE_ENTRY` in
 the end of the job execution attempt, and pre-fetched from the table in the beginning of the next attempt.
diff --git a/docs/filesystems/DataRepositoryService.md b/docs/filesystems/DataRepositoryService.md
@@ -15,7 +15,7 @@ The `auth` field refers to the authentication schema that should be used to auth
 
 The `drs` section needs to be added to
 - `engine.filesystems` block
-- [PapiV2](http://cromwell.readthedocs.io/en/develop/backends/Google) backend's `filesystems` block
+- [GCPBatch](http://cromwell.readthedocs.io/en/develop/backends/GCPBatch) backend's `filesystems` block
 
 
 **Localization Configuration**
diff --git a/docs/filesystems/Filesystems.md b/docs/filesystems/Filesystems.md
@@ -57,7 +57,7 @@ Those filesystems can be referenced by their name (`drs`, `gcs`, `s3`, `http` an
 
 **Note:**
 - **S3 filesystem is experimental.** 
-- **DRS filesystem has initial support only. Also, currently it works only with [GCS filesystem](../GoogleCloudStorage) in [PapiV2 backend](http://cromwell.readthedocs.io/en/develop/backends/Google).**
+- **DRS filesystem has initial support only. Also, currently it works only with [GCS filesystem](../GoogleCloudStorage) in the [GCP Batch backend](../backends/GCPBatch.md).**
 
 
 Also note that the local filesystem (the one on which Cromwell runs on) is implicitly accessible but can be disabled. 
@@ -95,7 +95,7 @@ engine {
 }
 ```
 
-(See the [Google section](../backends/Google.md) for information about the `auth` field.)
+(See the [Google section](../backends/GCPBatch.md) for information about the `auth` field.)
 
 We can now run this workflow
 
@@ -156,7 +156,7 @@ engine {
 ### Backend Filesystems
 
 Similarly to the engine, you can also configure backend filesystems individually. Some backends might require the use of a specific filesystem.
-For example, the [Pipelines API](../tutorials/PipelinesApi101.md) backend requires Google Cloud Storage.
+For example, the [GCP Batch](../tutorials/GcpBatch101.md) backend requires Google Cloud Storage.
 Let's take another example:
 
 ```wdl
diff --git a/docs/filesystems/GoogleCloudStorage.md b/docs/filesystems/GoogleCloudStorage.md
@@ -27,7 +27,7 @@ filesystems {
 }
 ```
 
-- The `auth` field refers to the authentication schema that should be used to authenticate requests. See [here](../backends/Google.md) for more info.
+- The `auth` field refers to the authentication schema that should be used to authenticate requests. See [here](../backends/GCPBatch.md) for more info.
 - The `project` field has to do with the Requester Pays feature (see below).
 - The `caching.duplication-strategy` field determines how Cromwell should behave w.r.t output files when call is being cached. The default strategy `copy` is to copy the file to its new call location. As mentioned, `reference` will not copy the file and simply point the results to the existing location.
 See the [Call Caching documentation](../cromwell_features/CallCaching.md) for more information.
diff --git a/docs/filesystems/HTTP.md b/docs/filesystems/HTTP.md
@@ -2,7 +2,7 @@
 
 ## Overview
 
-For shared filesystem and Google Pipelines API (PAPI) version 2 backends Cromwell can support workflow inputs specified by `http` and `https` URLs.
+For shared filesystem and Batch backends Cromwell can support workflow inputs specified by `http` and `https` URLs.
 Please note this is not true "filesystem" support for HTTP URLs;
 if inputs to a workflow are specified by HTTP URLs the outputs of steps will nevertheless appear at local or GCS paths and not HTTP
 URLs.
@@ -12,7 +12,7 @@ URLs.
 Cromwell's default configuration defines an instance of the HTTP filesystem named `http`. There is no additional configuration
 required for the HTTP filesystem itself so adding HTTP filesystem support to a backend is a simple as
 adding a reference to this filesystem within the backend's `filesystems` stanza. e.g. Cromwell's default `Local` shared filesystem
-backend is configured like this (a PAPI version 2 backend would be configured in a similar way):
+backend is configured like this (a GCP Batch or AWS backend would be configured in a similar way):
 
 ```
 backend {
diff --git a/docs/optimizations/CheckpointFiles.md b/docs/optimizations/CheckpointFiles.md
@@ -80,7 +80,5 @@ task count {
 
 ## Backend Support
 
-Cromwell supports the `checkpointFile` attribute on the following backends:
+Cromwell supports the `checkpointFile` attribute on the Google Batch backend
 
-* The Google PAPIv2 (alpha1) backend
-* The Google Life Sciences (beta) backend
diff --git a/docs/tutorials/Containers.md b/docs/tutorials/Containers.md
@@ -488,7 +488,7 @@ This is only necessary in local environments where there is no job manager to co
 Congratulations for improving the reproducibility of your workflows! You might find the following cloud-based tutorials interesting to test your workflows (and ensure the same results) in a completely different environment:
 
 - [Getting started with AWS Batch](AwsBatch101.md)
-- [Getting started on Google Pipelines API](PipelinesApi101.md)
+- [Getting started on GCP Batch](GcpBatch101.md)
 
 [cromwell-examples-conf]: https://www.github.com/broadinstitute/cromwell/tree/develop/cromwell.example.backends/cromwell.examples.conf
 [cromwell-examples-folder]: https://www.github.com/broadinstitute/cromwell/tree/develop/cromwell.example.backends
diff --git a/docs/tutorials/PipelinesApi101.md b/docs/tutorials/PipelinesApi101.md
diff --git a/docs/wf_options/Google.md b/docs/wf_options/Google.md
diff --git a/docs/wf_options/Overview.md b/docs/wf_options/Overview.md
