mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
Anso
ee75811e25
* feat(nodes): add capability-based node compatibility negotiation Each Sencho instance now exposes /api/meta with its version and supported capabilities. When the user switches nodes, the frontend fetches this metadata and disables features the remote node doesn't support via a CapabilityGate overlay. Version is shown in the node switcher dropdown and connection test results. - Backend: CapabilityRegistry with static capability list and fetchRemoteMeta helper - Backend: /api/meta (public) and /api/nodes/:id/meta (auth) endpoints - Frontend: NodeContext enhanced with per-node meta caching (5min TTL) - Frontend: CapabilityGate component with typed Capability union - Frontend: 13 features wrapped with capability gates - Docs: node-compatibility.mdx + OpenAPI spec updates * fix(nodes): revert to require() for package.json version reading The static import fails in the Docker multi-stage build because the root package.json is not copied into the backend-builder stage. The require() call resolves at runtime when the file is available.
82 lines
4.1 KiB
Plaintext
82 lines
4.1 KiB
Plaintext
---
|
|
title: Node Compatibility
|
|
description: How Sencho handles version differences across nodes and gracefully degrades features that aren't available on older instances.
|
|
---
|
|
|
|
When you manage multiple nodes, each running its own Sencho instance, those instances may be on different versions. A node running v0.28 won't have features that shipped in v0.31. Sencho detects this automatically and disables features that the active node doesn't support — no errors, no broken pages.
|
|
|
|
## How it works
|
|
|
|
Every Sencho instance exposes a `/api/meta` endpoint that returns its version and a list of **capabilities** — feature flags describing what that instance supports. When you switch to a node, your primary instance fetches this metadata and caches it for 5 minutes.
|
|
|
|
Features that require a capability the active node doesn't have are visually dimmed with an explanation overlay. Core features like stack management, containers, and resource monitoring are always available on every Sencho version.
|
|
|
|
## What you'll see
|
|
|
|
### Version in the node switcher
|
|
|
|
The sidebar node switcher shows each node's Sencho version next to its name. If a node is too old to report its version (pre-compatibility era), no version is shown.
|
|
|
|
### Disabled features
|
|
|
|
When you switch to a node that lacks a capability, the affected feature appears dimmed with a pill overlay explaining why:
|
|
|
|
> **Fleet Management** is not available — prod-server is running v0.28.0
|
|
|
|
The feature content is still visible (blurred) so you can see what you're missing, but it's non-interactive. Switch to a node that supports the feature, or update the remote node to the latest Sencho version.
|
|
|
|
### Connection test details
|
|
|
|
When you test a remote node's connection in **Settings > Nodes**, the result now includes the remote Sencho version alongside Docker info, container counts, and system stats.
|
|
|
|
## Capability list
|
|
|
|
Every Sencho release includes a static list of capabilities. Here are the capabilities tracked as of the current version:
|
|
|
|
| Capability | Feature |
|
|
|-----------|---------|
|
|
| `stacks` | Stack management (always available) |
|
|
| `containers` | Container operations (always available) |
|
|
| `resources` | Resource monitoring (always available) |
|
|
| `templates` | App Store (always available) |
|
|
| `global-logs` | Global log viewer (always available) |
|
|
| `system-stats` | System statistics (always available) |
|
|
| `fleet` | Fleet management |
|
|
| `auto-updates` | Auto-update policies |
|
|
| `labels` | Stack labels |
|
|
| `webhooks` | Webhooks |
|
|
| `network-topology` | Network topology view |
|
|
| `notifications` | Alert notifications |
|
|
| `notification-routing` | Notification routing rules |
|
|
| `host-console` | Host console |
|
|
| `audit-log` | Audit log |
|
|
| `scheduled-ops` | Scheduled operations |
|
|
| `sso` | SSO authentication |
|
|
| `api-tokens` | API token management |
|
|
| `users` | User management |
|
|
| `registries` | Private registry management |
|
|
|
|
<Note>
|
|
Capabilities are flag-based, not version-based. Sencho never compares version numbers — it checks whether the remote node explicitly advertises support for a feature. This means the system stays forward-compatible as new features are added.
|
|
</Note>
|
|
|
|
## Handling older nodes
|
|
|
|
Nodes running a Sencho version from before the compatibility system was introduced (pre-v0.32) don't have the `/api/meta` endpoint. Sencho handles this gracefully:
|
|
|
|
- The version shows as blank in the node switcher
|
|
- All gated features appear as unavailable on that node
|
|
- Core features (stacks, containers, resources, logs) work normally
|
|
- No errors are thrown — the UI degrades cleanly
|
|
|
|
The fix is straightforward: update the remote node to the latest Sencho version. See the [upgrade guide](/operations/upgrade) for instructions.
|
|
|
|
## Interaction with license tiers
|
|
|
|
Some features require both a license tier (Skipper or Admiral) **and** node capability support. When both gates apply:
|
|
|
|
1. The license gate is checked first — if you're on the Community tier, you see the upgrade prompt
|
|
2. If your license covers the feature but the node doesn't support it, you see the compatibility overlay instead
|
|
|
|
This means you won't see confusing "upgrade to unlock" messages for features that wouldn't work on the active node anyway.
|