Skip to content

Ask whether the durable data tier is reachable at all #702

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
xmap merged 1 commit into from
Aug 21, 2026
Merged

Ask whether the durable data tier is reachable at all #702

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/deployments/2-bm/questions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -178,6 +178,7 @@ right person, or naming who that person is, is a complete answer to any row here
| HOST-3 | `Blocks-go-live` | What durable storage can the host write backups to that is not the host's own disk, and does the host's own disk survive the host being lost or rebuilt? A backup written beside the database protects against operator error and corruption and against nothing else. This row also carries a deadline: backup-repository encryption is fixed when the repository is first created and cannot be added afterwards, so the target has to be known before that step, not after. | a facility share or object store is reachable; local disk is an interim posture only | not yet | [Deployment](../../stack/deployment.md) |
| HOST-4 | `Blocks-go-live` | Who needs to reach CORA's web interface, and from where: the beamline network only, anyone on the APS network, remote users over VPN, or remote users without one? This decides whether CORA sits behind an existing APS proxy or brings its own, and whether it needs a certificate and a resolvable name. | beamline and APS-network access, behind a facility-provided proxy that terminates TLS | not yet | [Deployment](../../stack/deployment.md) |
| HOST-5 | `Nice-to-have` | Who administers the host, and does the operating account have rights to install a scheduled system job? CORA needs a timer to run backups and expire old ones. If that is not permitted, the schedule has to live inside the application instead, which is a different and slightly worse design worth choosing deliberately. | beamline-administered, with rights to install a system timer | not yet | [Deployment](../../stack/deployment.md) |
| HOST-6 | `Blocks-go-live` | Is the APS Data Management tree (`/gdata/dm/2BM/`) readable from `tomdet`, using the same account CORA's scan probe already logs in with? The 2026-08-11 check covered `arcturus` only, and found `/gdata` invisible there; whether `tomdet` can see it was never tested. It matters because the DM copy is the one that outlives the beamtime, and every upstream tier is capacity-purged, so a record that names only `/local1` points at bytes that will be gone. If `tomdet` cannot read it either, naming the host that can, or the supported way to list and read an experiment folder there, is an equally complete answer. | readable on `tomdet` over the existing SSH account, read-only | not yet | [Operations](operations.md#supplies) |

## Not on this page

Expand Down
Loading