Migrate collection WV04_Pan_L1B to CBA Prod

[chuckwondo]

Migrate granules in collection WV04_Pan_L1B to CBA Prod by discovering/ingesting from existing prod account.

Although this collection is quite small (6753 granules), spanning only 2 years, before migrating the entire collection we must do the following:

• [x] Enable the rule WV04_Pan_L1B___1_SmokeTest
• [x] Run the rule WV04_Pan_L1B___1_SmokeTest
• [x] Confirm the granules in the temporal range of the smoke test appear in Earthdata Search with the correct download links (specifically, make sure the host is data.csdap.earthdata.nasa.gov, with a csdap, not csda -- if missing the p, they point to the "old" prod bucket)
• [x] Confirm they can be found in Kibana (metrics.earthdata.nasa.gov) for the correct time of the smoke test execution
• [x] Confirm you can download (with Cognito auth) a file from the download list shown in Earthdata Search
• [x] Confirm the visibility of the thumbnails in the Earthdata Search results

Once all the above is confirmed, ingest the full collection as follows:

• [x] In package.json, change 66641bb to 68b8eb5 for the hash value of the cumulus-cli dependency in the devDependencies list (this will add the ability to show request/response details when running cumulus CLI commands, which will be used in the acceptance criteria below)
• [x] In app/stacks/cumulus/resources/rules/WV04_Pan_L1B/v1/WV04_Pan_L1B___1.json, change the value of meta.discoverOnly to false (it was set to true for the dry run #292 to avoid publishing to the CMR at that time)
• [x] Replace the rule (cumulus rules replace --data app/stacks/cumulus/resources/rules/WV04_Pan_L1B/v1/WV04_Pan_L1B___1.json)
• [x] Enable the rule (cumulus rules enable --name WV04_Pan_L1B___1)
• [x] Run the rule (cumulus rules run --name WV04_Pan_L1B___1)

Acceptance criteria

All granules in WV04_Pan_L1B have been ingest into CBA Prod. To confirm this, first enter the Docker container:

DOTENV=.env.cba-prod make bash

In the container, run the following:

DEBUG=1 cumulus granules list -? collectionId=WV04_Pan_L1B___1 --limit=0

You should see output similar to the following:

...
RESPONSE: {
  statusCode: 200,
  body: '{"meta":{"name":"cumulus-api","stack":"cumulus-prod","table":"granule","limit":0,"page":1,"count":0},"results":[]}',
  headers: {
    'x-powered-by': 'Express',
    'access-control-allow-origin': '*',
    'strict-transport-security': 'max-age=31536000; includeSubDomains',
    'content-type': 'application/json; charset=utf-8',
    'content-length': '114',
    etag: 'W/"72-O2wUXhu+Q9J1hqdDrb0fcsZeFHo"',
    date: 'Fri, 01 Dec 2023 21:29:19 GMT',
    connection: 'close'
  },
  isBase64Encoded: false
}
[]

In particular, look at the value for body and within it, locate the value of "count". In the output above, the count is 0, but when the collection is fully ingested, it should be 6753.

[chuckwondo]

We successfully ingested all but 1 granule, WV04_20170808074723_34ae45a8-7b48-4962-adb9-f257b50b70a5-inv_17AUG08074723-P1BS-059102583090_01_P005.

This granule was missing its cmr.json file, so the ingest workflow failed because of that. We do not need to take any action at this point because when we sync up the mcp bucket and reingest from there, it should get picked up at that time (assuming the cmr.json file is in the mcp bucket).

[jsrikish]

The granule which did not get ingested has a cmr.json to it. Here's the link:

s3://csdap-maxar-delivery/css/nga/WV04/1B/2017/220/WV04_34ae45a8-7b48-4962-adb9-f257b50b70a5-inv_X1BS_059102583090_01/WV04_20170808074723_34ae45a8-7b48-4962-adb9-f257b50b70a5-inv_17AUG08074723-P1BS-059102583090_01_P005-cmr.json

It can be ingested in the next round of ingestion from MCP to CBA