diff --git a/docs/deployments/2-bm/questions.md b/docs/deployments/2-bm/questions.md index f4ada12df7..f9ba940f10 100644 --- a/docs/deployments/2-bm/questions.md +++ b/docs/deployments/2-bm/questions.md @@ -133,17 +133,26 @@ all of them block pointing CORA at anything real. Whether the host is a virtual bare metal is CORA's problem to accommodate and not a question for this page. What the host can reach, and what survives losing it, are not. +Decided 2026-08-11, internally rather than as a staff question: CORA runs on `arcturus` for now. +`arcturus` already carries a shared installation CORA can use, `conda activate cora` under the shared +`/home/beams/2BMB` home directory, confirmed directly reachable there with no extra hop. This is an +interim choice for testing and development while nothing structured is decided yet, and the host may +move later. Two consequences follow. `arcturus`'s own `EPICS_CA_ADDR_LIST` (an explicit address list, +not broadcast) is simply what CORA now uses, which is what the former HOST-1 asked. And read access to a +finished scan file has a working interim answer that needs no mount and never touches the beamline's +write paths: read the file in place over SSH to `tomdet`, the same way `test_003.h5` was inspected on +2026-08-11 (see [Operations](operations.md#inside-the-scan-file)). The durable version of that question, +a mount or a supported fetch path, stays open below. + These are likely controls, networking, or IT questions rather than floor questions. Routing them to the right person, or naming who that person is, is a complete answer to any row here. | ID | Priority | Question | CORA assumes | Already done? | Resolves | | --- | --- | --- | --- | --- | --- | -| HOST-1 | `Blocks-go-live` | Is the host on the same network segment as the beamline IOCs, and if it is not, which Channel Access gateway or address list should it use? EPICS CA finds PVs by UDP broadcast on the local subnet by default, so a host one routed hop away sees nothing and reports it as a timeout rather than an error. Naming the gateway makes it a configuration line; leaving it unstated makes it a day of debugging that looks like a CORA fault. | the host can reach the IOCs, with an explicit address list rather than broadcast discovery (confirmed 2026-08-11: `arcturus` itself uses `EPICS_CA_ADDR_LIST=164.54.113.168 10.54.113.24:16661`, not broadcast; whether CORA's host gets this same list, or needs its own, is asked of Francesco pending HOST-6) | not yet | [Deployment](../../stack/deployment.md) | -| HOST-2 | `Blocks-go-live` | Can the host read the scan files directly, as a mount of the analysis tier (`/data2`, `/data3`) or of the Sojourner experiment tree, and read-only is sufficient? If no mount is possible, what is the supported way for an off-host reader to fetch a finished file? The answer decides whether CORA reads a dataset in place or has to copy it first, which is a different design and not a setting. | a read-only mount of at least one tier holding finished scan files (confirmed 2026-08-11: none of `/local1`, `/data2`, `/data3`, `/gdata/dm/2BM` are visible from `arcturus`; finished files land on `tomdet` at `/local2/2BM//`, not `/local1` as Operations previously said; whether CORA's host gets a mount of that tier is asked of Francesco pending HOST-6) | not yet | [Operations](operations.md#inside-the-scan-file) | +| HOST-2 | `Blocks-go-live` | Can the host read the scan files directly, as a mount of the analysis tier (`/data2`, `/data3`) or of the Sojourner experiment tree, and read-only is sufficient? If no mount is possible, what is the supported way for an off-host reader to fetch a finished file? The answer decides whether CORA reads a dataset in place or has to copy it first, which is a different design and not a setting. | a read-only mount of at least one tier holding finished scan files (confirmed 2026-08-11: none of `/local1`, `/local2`, `/data2`, `/data3`, `/gdata/dm/2BM` are visible from `arcturus`; finished files land on `tomdet` at `/local2/2BM//`, not `/local1` as Operations previously said; the interim posture is a read-in-place SSH hop to `tomdet`, not a mount) | not yet | [Operations](operations.md#inside-the-scan-file) | | 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` | Which host does CORA actually run on: `arcturus`, `tomdet`, or a separate machine? `arcturus` and `tomdet` do not see the same filesystems or the same PVs (HOST-1, HOST-2), so this decides both. Found 2026-08-11: a `cora` conda env already exists on `tomdet` (Python 3.13.14, matching CORA's pinned version, `uv` installed, a couple of FastAPI-adjacent packages), but nothing is installed in it. Was that staged on purpose for this? | `tomdet`, since that is where the pre-staged environment and the scan files both are | not yet | [Deployment](../../stack/deployment.md) | ## Not on this page