dohertj2/scadalink-design
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(notification-outbox): fix stale cross-references after outbox addition

Browse Source
This commit is contained in:
Joseph Doherty
2026-05-18 23:45:43 -04:00
parent ba166bf503
commit bb35453d58
9 changed files with 41 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/requirements/Component-DeploymentManager.md
View File

@@ -17,7 +17,7 @@ Central cluster only. The site-side deployment responsibilities (receiving confi
- Track deployment status (pending, in-progress, success, failed).
- Handle deployment failures gracefully — if a site is unreachable or the deployment fails, report the failure. No retry or buffering at central.
- If a central failover occurs during deployment, the deployment is treated as failed and must be re-initiated.
- Deploy system-wide artifacts (shared scripts, external system definitions, database connection definitions, data connection definitions, notification lists, SMTP configuration) to all sites or to an individual site on explicit request.
- Deploy system-wide artifacts (shared scripts, external system definitions, database connection definitions, data connection definitions) to all sites or to an individual site on explicit request.
- Send instance lifecycle commands (disable, enable, delete) to sites via the Communication Layer.
## Deployment Flow
@@ -106,30 +106,13 @@ A deployment to a site includes the flattened instance configuration plus any sy
- External system definitions
- Database connection definitions
- Data connection definitions
- Notification lists
- SMTP configuration
System-wide artifact deployment is a **separate action** from instance deployment, triggered explicitly by a user with the Deployment role. Artifacts can be deployed to all sites at once or to an individual site (per-site deployment via the Sites admin page).
### Secret handling in artifacts
The SMTP configuration artifact carries the SMTP credential (password or OAuth2
client secret). This is a **conscious, accepted design decision**: SMTP
configuration is a deployable artifact, so the credential is distributed to
sites that need it. The credential is protected by the following controls:
- **In transit** — artifact-deployment commands travel over the inter-cluster
transport, which is TLS-protected (see Cluster Infrastructure / Communication).
- **Not logged** — the Deployment Manager never writes credential values to
logs; deployment log statements reference only site IDs/names, the deployment
ID, and exception messages.
- **At rest on the site** — the credential is stored in the site's local SQLite
artifact store. At-rest encryption of that field is **not** currently applied;
it is treated as acceptable given the TLS-protected transport, the absence of
any logging leak, and the trust boundary of the site host. Encrypting the
credential field within the artifact payload would require a key-management
scheme (key location and distribution to sites) and is recorded here as a
possible future hardening item, not a current requirement.
Notification lists and SMTP configuration are **not** deployable artifacts — they
are central-only definitions managed by the Notification Service. Notification
delivery happens on the central cluster (see Component-NotificationOutbox.md), so
no notification artifact or SMTP credential is ever distributed to sites.
## Site-Side Apply Atomicity