From cd3494e4f7905847e43ac4d23a33d9784293ebaa Mon Sep 17 00:00:00 2001 From: xmap <16776958+xmap@users.noreply.github.com> Date: Thu, 20 Aug 2026 23:11:46 -0500 Subject: [PATCH] Ask whether the durable data tier is reachable at all The plan for registering the DM-tier copy of a scan file rested on /gdata/dm/2BM being readable from tomdet, over the SSH hop the scan probe already uses. That was never established. The 2026-08-11 check behind HOST-2 found /gdata invisible from arcturus and covered no other host, so the tomdet case is untested rather than confirmed. It gates a design rather than a setting: if tomdet cannot see the tree, CORA needs a different host or a DM-side listing interface to observe the durable copy, which is a different slice from the one planned. Ask the beamline instead of assuming, and accept a pointer to whichever host can read it as an equally complete answer. --- docs/deployments/2-bm/questions.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/deployments/2-bm/questions.md b/docs/deployments/2-bm/questions.md index 2d114b81d62..0ab82fd1949 100644 --- a/docs/deployments/2-bm/questions.md +++ b/docs/deployments/2-bm/questions.md @@ -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