[deckhouse-cli] Plugins / d8 self-update with requirements check

[Glitchy-Sheep]

Summary

Adds two ways to keep d8 current, both reaching the cluster registry only through the in-cluster registry-packages-proxy (RPP), authenticated by the caller's kubeconfig identity:

• d8 cli - update the d8 binary itself.
• d8 plugins - install, update, run and remove plugins (standalone binaries that behave like native subcommands).

No registry credentials are handed to users: access is an ordinary RBAC grant on the proxy, so an admin decides who may download and can revoke per-identity. Plugin operations validate the plugin's declared requirements before anything is downloaded or switched.

Why

• Let utilities (system, delivery, ...) ship and version independently of the d8 core, while still installing as native-looking subcommands.
• Keep d8 itself compact - pull only what a user actually invokes.
• Replace per-user registry secrets with the existing cluster identity: the proxy holds the registry credentials, the user presents a kubeconfig Bearer token.

How a request reaches the registry

flowchart LR
    U["d8 cli update / d8 plugins install"] -->|"Bearer token from kubeconfig"| ING["Ingress (auto-discovered)<br/>pod-IP fallback"]
    ING --> KRP["kube-rbac-proxy<br/>TokenReview + SubjectAccessReview"]
    KRP -->|"cli-download RBAC role"| RPP["registry-packages-proxy"]
    RPP --> REG["cluster registry"]

Loading

The endpoint is discovered from the cluster (public Ingress preferred, master pod-IP as fallback) or set explicitly with --rpp-endpoint. TLS is verified against system roots or a supplied CA; redirects are refused so the Bearer token never leaves the proxy host.

New commands

d8 cli - update d8 itself

• check - report whether a newer published version exists.
• versions (alias list) - list published versions newest-first; the active one is starred, locally installed ones are marked.
• update [--version X] - install a version into the per-user store, smoke-test it, then point the binary at it. --version also downgrades.
• use <version> - switch versions: an installed one is an instant offline symlink repoint (no cluster, no sudo); a missing one is downloaded first.

Versions live in a per-user store and the active one is chosen by a current symlink, so switching copies nothing:

<d8 in PATH>  ->  ~/.deckhouse-cli/cli/current  ->  versions/<tag>/d8
   (migrated once to a symlink; the original is kept as <exe>.old)

d8 plugins - manage plugins

• install <name> [--version X | --use-major N | --force | --resolve-plugins-conflicts] - install or switch a plugin version; requirements are checked first.
• update <name> / update all - move to the newest cluster-compatible version within the installed major.
• versions <name> - list a plugin's published versions.
• contract <name> - show a plugin's contract (version, description, requirements) without installing.
• list - list installed plugins (the proxy serves no catalog, so available plugins are addressed by name).
• remove <name> / remove all - uninstall.

A plugin image carries the binary plus a contract.yaml describing its env vars, flags and requirements. When DECKHOUSE_PLUGINS_ENABLED=true, the built-in system command is served by a plugin wrapper that installs it on first use, then execs it with arguments forwarded verbatim and contract-requested env injected.

Safe install and update

Every install/update runs under a per-component lock as an all-or-nothing pipeline, so a failure never leaves a half-swapped or broken binary:

flowchart TD
    A["acquire install lock"] --> B["validate requirements (before any download)"]
    B -->|"unmet"| Z["abort - nothing downloaded or changed"]
    B -->|"ok"| C["download to staged sibling .new"]
    C --> D["smoke test (--version)"]
    D -->|"fails"| Z2["abort - live binary untouched"]
    D -->|"passes"| E["atomic rename over the live binary"]
    E --> F["cache the contract"]
    F --> G["repoint the current symlink"]

Loading

Self-update follows the same shape: a downloaded binary is smoke-tested before it can become current, and a failed download leaves the running binary in place.

Requirements model

Validated against a single cluster snapshot taken per command:

• Kubernetes / Deckhouse / module constraints - checked only when the contract declares them; a snapshot that cannot be built is a hard error (override with --skip-cluster-checks for testing).
• Plugin-to-plugin dependencies:
  • mandatory - the dependency must be installed and satisfy the constraint; --resolve-plugins-conflicts auto-installs missing ones and re-validates, failing if a resolved version still does not satisfy the constraint.
  • conditional - enforced only when the dependency is already installed.
• Version selection picks the newest stable semver compatible with the cluster; pre-releases are excluded by default, an implicit pick never downgrades a newer installed version, and requirements are re-checked before every plugin run.

Example usage

Self-update (d8 cli)

See what is published and which version is active:

Check whether a newer version exists:

A mandatory plugin dependency that is not installed (retry with --resolve-plugins-conflicts to pull it in):

A typo in plugins versions leads to a user-friendly error

A typo in version to update to is also leading to a user-friendly error

Configuration

Flag	Env	Purpose
--kubeconfig / --context	KUBECONFIG	cluster identity (Bearer token)
--rpp-endpoint	D8_RPP_ENDPOINT	proxy base URL (auto-discovered if unset)
--rpp-ca-file / --rpp-insecure-skip-tls-verify	D8_RPP_CA_FILE	proxy TLS (custom CA / skip)
--plugins-dir	DECKHOUSE_CLI_PATH	plugins root (default /opt/deckhouse/lib/deckhouse-cli, home fallback when not writable)
--skip-cluster-checks	D8_PLUGINS_SKIP_CLUSTER_CHECKS=1	downgrade cluster-side requirement checks to warnings
-	DECKHOUSE_PLUGINS_ENABLED=true	enable the plugin subsystem (staged rollout)

What is new under the hood

• internal/rpp - the proxy client: endpoint discovery, kubeconfig-identity transport (TLS, redirect ban, size limits), routes, tar.gz extraction.
• internal/selfupdate - the d8 cli tree, the versioned store and the atomic switch flow.
• internal/plugins - the plugin machinery (install / run / select / validate / update / remove) with thin cobra wrappers in internal/plugins/cmd.
• internal/lockfile - cross-process exclusive locks shared by self-update and plugin installs.
• pkg/registry/service/contract.go - the shared contract decoder. The direct-registry plugin path is removed: the proxy is the only source.

User docs: docs/self-update.md, docs/plugins.md; package notes in internal/selfupdate/README.md, internal/plugins/README.md.

Tests

• Unit coverage across internal/rpp, internal/selfupdate, internal/plugins (+ requirements, cmd), internal/lockfile, pkg/registry/service.
• Proxy-emulating tests (rpp_source_test.go in plugins and selfupdate) drive the full path against an in-process TLS server: list tags, pull, extract, atomic swap, smoke test, platform-tag preference.
• Targeted regression tests for the install pipeline: requirements gate before download, conflict-resolution re-validation, smoke-failure rollback, and self-update PATH-migration rollback.

Notes

• This branch deliberately ships manual-only delivery. Earlier commits added background auto-update, a startup notice and a cli cron command; they were removed - d8 downloads or replaces nothing without an explicit command.
• The branch also carries two small unrelated tidy-ups: iam access slice preallocation and sig-migrate formatting.