mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
Anso
d03d97d964
* fix(nodes): close capability-gating gaps in node compatibility Vulnerability scanning is now gated correctly on whether the active node advertises support for it: - A node without the Trivy binary stops advertising the scanning capability. Previously the capability was toggled only on a state change, so a node that booted without Trivy kept advertising scanning it could not perform. - The control node's own capability list now reflects features disabled at runtime, matching what it advertises to peers. - The scan history surface shows a clear "not available on this node" card, with its header actions hidden, instead of attempting a request that fails. A node's version and capability metadata now refreshes immediately after a connection test or a completed update, rather than waiting out the cache. Capability gates fail closed to the unavailable card when a node's metadata request errors, instead of staying open until the next fetch. Adds a test that fails if the frontend and backend capability lists drift, plus coverage for the metadata error path, the runtime-disabled local meta, the scanning capability sync, and the metadata cache invalidation paths. * fix(nodes): refresh node metadata client-side after a connection test A connection test dropped the server-side metadata cache, but the dashboard kept its own cached copy until the client TTL expired, so version and capability gates could stay stale in the browser. The test now forces a client-side metadata refresh for that node, so the version pill and gates reflect the node's current state immediately. Also strips any URL userinfo before logging the metadata fetch target, and makes the scanning-capability detection test deterministically exercise the no-binary disable path rather than depending on whether the runner has Trivy.
103 lines
7.0 KiB
Plaintext
103 lines
7.0 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 (briefly on the server, and for 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 seven nodes. The Local row reads LOCAL · v0.81.11 with a star icon for the default node. Three remote rows read REMOTE · v0.81.11. The sencho-pilot-test row reads AGENT · SEEN 20M AGO · v0.76.9, calling out that this node is on an older release than the rest of the fleet." />
|
|
</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 freshly-enrolled remotes may show their type chip alone until you switch to them once. 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 Host Console is not available on this node and a body line reads sencho-pilot-test is running v0.76.9. 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 sencho-test-01 showing Instance: Remote Sencho, Sencho: v0.81.11, OS: Remote, Arch: Remote, Containers: 1, Images: 21, CPUs: 1, 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 |
|
|
| `host-console` | Host Console |
|
|
| `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 |
|
|
|
|
<Note>
|
|
`vulnerability-scanning` is advertised only when the Trivy binary is present on the node. If a node does not have Trivy installed, it omits this capability and the scanning UI is replaced by a lock card.
|
|
</Note>
|
|
|
|
## 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 a license tier (Skipper or Admiral) **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 license already covers, so it is always actionable: upgrading the node will unlock the feature.
|