mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
Anso
dd54a2e483
* feat: graduate Host Console to Community admins Make Host Console available to Community and Admiral admins (system:console), add host-console-community for mixed fleets, and keep opaque API tokens off the host shell. * docs: document Host Console deep links Cover root and stack-scoped Console URLs, correct the phone treatment note, and pin parse/build round-trips in senchoRoute tests. * fix: bind Host Console socket to the resolved node Treat unresolved activeNode as loading, target the WebSocket with an explicit nodeId, and wait for stack deep-link hydration so the shell cannot open on the wrong node or compose root. Add regression coverage for node/stack retargeting and fail-closed directory resolution. * fix: harden Host Console node binding, audit acting_as, and console_session tokens Reject unknown or malformed nodeIds before spawning a PTY. Record hub operators in audit_log.acting_as for remote console_session bridges. Path-scope and one-time-consume console_session JWTs so Host Console mints cannot open container exec or be replayed. * test: expect acting_as in audit CSV export header Align the CSV export assertion with the P0-2B acting_as column added to audit log exports.
127 lines
9.5 KiB
Plaintext
127 lines
9.5 KiB
Plaintext
---
|
|
title: Node Compatibility
|
|
description: How Sencho handles version differences across nodes and gracefully gates features that are not available on the active node.
|
|
---
|
|
|
|
When you manage [multiple nodes](/features/multi-node), each running its own Sencho instance, those instances may be on different versions. A node running an older release will not have features that shipped in a newer one. Sencho detects this automatically and gates each feature on whether the active node advertises support for it, with no errors and no broken pages.
|
|
|
|
## How it works
|
|
|
|
Every Sencho instance exposes a public `GET /api/meta` endpoint that advertises its version and a list of **capabilities**, one flag per feature it implements. When you switch to a node, your control instance fetches that node's metadata and caches it (3 minutes on the server, and 5 minutes on success or 30 seconds on failure in the dashboard), so the version pill and the per-feature gates stay in sync without re-hitting the remote on every navigation. Testing a node from **Settings · Nodes**, or a node finishing an update, refreshes its metadata right away rather than waiting for the cache to expire.
|
|
|
|
Features whose capability is missing from the active node's list are replaced by a lock card naming the missing feature and prompting you to upgrade the node. Core features (stack management, containers, resources, logs) work on every Sencho version and are never gated this way.
|
|
|
|
<Note>
|
|
Capabilities are flag-based, not version-based. Sencho never compares version numbers; it checks whether the active node explicitly advertises support for each feature. This keeps the system forward-compatible as new capabilities are added.
|
|
</Note>
|
|
|
|
## What you will see
|
|
|
|
### Version in the node switcher
|
|
|
|
The node switcher popover shows each node's Sencho version next to its type chip, separated by a middle dot.
|
|
|
|
<Frame>
|
|
<img src="/images/node-compatibility/node-switcher-versions.png" alt="Node switcher popover listing four connected nodes. The Local row reads LOCAL · v0.95.0 with a star icon for the default node. The Opsix row reads REMOTE · v0.95.0. The Pitt-Moba and SLX-Mars rows read REMOTE only, with no version pill, because this dashboard session has not switched to them yet." />
|
|
</Frame>
|
|
|
|
A node's version pill appears once Sencho has fetched its metadata. The metadata cache populates the first time you visit a node, so a node you have not switched to yet in the current session shows its type chip alone, with no version pill, until you do. A node that does not return metadata at all shows no version pill on either visit.
|
|
|
|
### Lock card on unsupported features
|
|
|
|
When the active node does not advertise a capability that a feature needs, the feature panel is replaced by a centered lock card.
|
|
|
|
<Frame>
|
|
<img src="/images/node-compatibility/lock-card.png" alt="Capability lock card centered in the editor area. A circular icon badge holds an Unplug glyph at the top. Below it, a title reads Audit Log is not available on this node and a body line reads Local is running v0.95.0. Upgrade the node to use this feature." />
|
|
</Frame>
|
|
|
|
The card carries the feature name, the node name, and (when known) the running version, so you can see at a glance what is missing and where. When the node has not reported a version, the body line drops the version and reads "*node-name* does not advertise this capability. Upgrade the node to use this feature." instead. The gated panel itself does not load; the lock card replaces it, which keeps slow capability-heavy views from briefly flashing into view before being hidden.
|
|
|
|
### Connection test details
|
|
|
|
When you test a remote node from **Settings · Nodes**, the Connection Details panel that appears under the table lists the node's running Sencho version alongside its OS, architecture, container count, image count, and CPU count.
|
|
|
|
<Frame>
|
|
<img src="/images/node-compatibility/connection-test-version.png" alt="Connection Details panel for Opsix showing Instance: Remote Sencho, Sencho: v0.95.0, OS: Remote, Arch: Remote, Containers: 4, Images: 4, CPUs: 2, with a wifi-style icon in the heading." />
|
|
</Frame>
|
|
|
|
This is the most direct way to confirm what version a remote node is on without switching to it first.
|
|
|
|
## Capability list
|
|
|
|
Every Sencho release ships with a static list of capabilities. The current list is:
|
|
|
|
| Capability | Feature |
|
|
|-----------|---------|
|
|
| `stacks` | Stack management (always available) |
|
|
| `containers` | Container operations (always available) |
|
|
| `resources` | Resource browser (always available) |
|
|
| `templates` | App Store (always available) |
|
|
| `global-logs` | Global log viewer (always available) |
|
|
| `system-stats` | Host system statistics (always available) |
|
|
| `fleet` | Fleet management view |
|
|
| `auto-updates` | Auto-Update policies |
|
|
| `labels` | Stack labels |
|
|
| `webhooks` | Webhook triggers |
|
|
| `network-topology` | Network topology view |
|
|
| `notifications` | Alert notifications |
|
|
| `notification-routing` | Notification routing rules |
|
|
| `notification-suppression` | Mute rules |
|
|
| `host-console` | Host Console (legacy advertisement retained for mixed-version fleets) |
|
|
| `host-console-community` | Host Console without a paid-license requirement on this node |
|
|
| `container-exec` | Container exec terminal |
|
|
| `audit-log` | Audit log |
|
|
| `scheduled-ops` | Scheduled operations |
|
|
| `sso` | SSO authentication |
|
|
| `api-tokens` | API token management |
|
|
| `users` | User management |
|
|
| `registries` | Private registry management |
|
|
| `self-update` | Self-update from the dashboard |
|
|
| `vulnerability-scanning` | Image vulnerability scanning |
|
|
| `compose-doctor` | Compose Doctor preflight |
|
|
| `update-guard` | Pre-update rollback-readiness dialog |
|
|
| `compose-networking` | Stack Networking tab |
|
|
| `env-inventory` | Stack Environment tab (env var inventory) |
|
|
| `container-label-inventory` | Stack Compose Labels tab and Fleet label filters |
|
|
| `project-env-files` | Project-level env file selection in the Environment tab |
|
|
| `compose-storage` | Stack Storage tab (volume explorer) |
|
|
| `cross-node-rbac` | Role enforcement on requests forwarded to a remote node |
|
|
| `stack-down-remove-volumes` | The "also remove volumes" option on Take Down |
|
|
| `guided-external-network-preflight` | Guided missing-external-network check before deploy |
|
|
| `service-scoped-update` | Per-service update, rebuild, and restore on multi-service stacks |
|
|
|
|
<Note>
|
|
`vulnerability-scanning` is advertised only when the Trivy binary is present on the node. If a node has no scanner installed, it omits this capability and the scanning UI is replaced by a lock card whose body reads "Install a scanner from the Scanner setup tab." instead of the generic upgrade message.
|
|
</Note>
|
|
|
|
<Note>
|
|
A node connected in [Pilot Agent](/features/multi-node#add-a-remote-node-pilot-agent) mode never advertises `host-console` or `host-console-community`, even after upgrading, because that feature's control-to-agent path is not yet wired through the enrollment tunnel. This is the one capability gap that upgrading the node cannot close; it only closes on a Distributed API Proxy connection.
|
|
</Note>
|
|
|
|
A handful of capabilities gate a smaller piece of behavior rather than a whole panel, so a missing one falls back to an older behavior instead of a lock card:
|
|
|
|
- Nodes that do not advertise `guided-external-network-preflight` keep legacy deploy behavior (no guided missing-external dialog). When the capability is present but the check cannot run, deploy fails closed instead of guessing.
|
|
- Nodes that do not advertise `service-scoped-update` fall back to the legacy per-container layout on multi-service stacks: no declared-service headers, and no per-service update, rebuild, or restore.
|
|
- Nodes that do not advertise `update-guard` run manual updates directly, with no pre-update rollback-readiness dialog.
|
|
- `cross-node-rbac` is a security boundary, not a convenience: the control instance refuses to forward a non-admin request, or a confirmed stop-by-label, to a remote node that does not advertise it. This stops a mixed-version fleet from letting a lower-privileged action escalate on an un-upgraded node.
|
|
|
|
## Handling nodes that do not advertise metadata
|
|
|
|
If a remote node does not respond to `/api/meta` (for example, an unreachable instance, a slow handshake, or one that does not implement the endpoint), Sencho falls back to an offline metadata record with no version and an empty capability list. In that state:
|
|
|
|
- The node's row in the switcher and the connection-test panel show no version pill.
|
|
- Every capability-gated feature on that node shows the lock card.
|
|
- Core features (stacks, containers, resources, logs) continue to work normally.
|
|
- No errors are surfaced in the UI; the control instance retries the metadata fetch after a short backoff.
|
|
|
|
If you expect a node to support a feature that is being gated, the fastest fix is to update that node to the latest Sencho release. See the [upgrade guide](/operations/upgrade) for instructions.
|
|
|
|
## Interaction with license tiers
|
|
|
|
Some features need both an Admiral license **and** node capability support. The two gates evaluate in this order:
|
|
|
|
1. The license gate is checked first. On the wrong tier, the feature's entry point (sidebar item, top-nav button, settings section) is hidden entirely, so you never reach the panel.
|
|
2. If you are on the right tier but the active node does not advertise the capability, the entry point is visible but the panel is replaced by the capability lock card.
|
|
|
|
The practical effect is that you only see the lock card for features your plan already covers, so it is always actionable: upgrading the node restores access to that feature.
|