Repository navigation
What's new in 0.5.0
New
- Fleet console (ADR 0077). One installation manages the others: the Sites page lists every installation with its version, role, HA copies, mirrors and updates.
- Pairing uses a one-time code and pinned TLS. Site keys are sealed outside the database and work only on a fixed list of routes.
- The catalog of a managed site can be browsed from the controller.
- From the controller you can change a site's download queue and updates, attach, re-key and detach mirrors, switch over an HA cluster and accept a single copy for a while. Changes are applied on the site by its privileged agent, with the same checks as
arkvory configureandcluster-*. - Fleet state: alerts (unreachable, certificate, missing copies, failing or lagging mirrors, failed updates, version skew), a map of mirror links, fleet metrics and Prometheus rules.
ARKVORY_SITE_URLandARKVORY_FLEET_LAG_ALERTconfigure the map and the lag alert.
- Download queue (ADR 0076). Large downloads are admitted as whole-download sessions rather than per range, so a started download is not interrupted between ranges.
- Priority classes:
interactive,release,bulkandbackground. Strategies:ordered,smallest-firstandshared. - Clients get their place and an estimated start time.
- Queue tickets keep a download's turn across a server restart.
- The queue settings can be changed at runtime from the console or the API, without a restart.
- Priority classes:
- Waiting instead of failing. The SDK and
arkvoryctlwait when the server is busy (503 busy,429withRetry-After) and do not spend their retry budget on it.--wait-limitandwaitLimitMscap the wait.--not-beforeand--not-after(notBefore/notAfterin the SDK) set a client time window.
- Mirrors and Cluster pages in the console. Each mirror and import shows its source, state, last sync and the reason it stopped, with the command that fixes it. The cluster page shows the layout, the serving node, copies and the next step.
GET /api/v1/mirrorsis new. - Conflicting mirror entries are put aside. A conflicting package version or a taken ID no longer stops a mirror or import feed. The entry is set aside and retried until it applies. It shows in the mirror status, the console, the metric
arkvory_mirror_conflictsand the alertArkvoryMirrorConflicts.
Reliability
- The worker no longer exits when mirror startup hits a database or file error. It retries, and jobs, GC and webhooks keep running.
- The managed PostgreSQL is no longer stopped during a long crash recovery, and a clean stop is no longer reported as a failure.
- On Windows, the installer reserves the managed database port (
netsh ... excludedportrange), so Hyper-V cannot take it after a reboot. Uninstalling releases the reservation. - An unreadable update request no longer blocks the updater.
cluster-nodeandcluster-releasenever touch a disk that is not their DRBD volume, and they take the installation lock.- A switchover waits on a monotonic clock.
- A mirror re-attached to a different source is refused. A re-attach after local changes is refused, even when those changes were made just after a detach.
- Fleet polling stops on shutdown, and requests from a closed console tab are cancelled.
- Download estimates stay correct with parallel ranges.
- The console keeps refreshing after a failed request.
Updating
- This release changes the database schema (migrations 37–41). As with 0.4.0, the update installs only after a fresh verified backup. Either connect a backup vault (
arkvory configure --backup-vault <dir> --init-vault) and let the first backup finish, or take an operator backup and runupgrade --backup-record <file>. Without either, the update is refused before anything changes, and 0.4.0 keeps running. - Tested for this release: 0.4.0 → 0.5.0 with the
.debon Linux/systemd and with Docker Compose on Windows; content was kept.
Known limitations
- The fleet map and alerts do not show the count of mirror entries set aside.
- Image, Git LFS and npm entries are never set aside: their order matters, so a conflict there still stops the feed.
- The time windows for the download classes and the classes of service accounts come in a later release.
All release gates passed for this commit on the maintainer workstation (local CI). The release is signed (arkvory-release.json.sig, latest.json). Review deployment notes and platform evidence before publishing; after publishing, approve the version for a channel in the hub.
Release gates (0.5.0)
Arkvory local CI: PASSED
Profile release, commit eb80cc3c4b9033f0555263ca92bc736d3da13eb9.
Host: Windows_NT 10.0.22621, Node v24.13.0, Docker 29.4.3.
| Lane | Environment | Status | Gates |
|---|---|---|---|
| windows | windows-host | passed | static, unit, security, integration, browser, docs, deployment, deployment-containers, native-package, large-full, large-multipart |
| linux | linux-container | passed | static, unit, integration, browser, deployment |
| linux-system | linux-systemd-container | passed | native-package, deployment-services, native-install, deployment-stand |
Not executed locally:
- deployment-services (win32): Installs Windows services; runs only on a disposable GitHub Actions runner
- native-install (win32): Installs the Windows package machine-wide; runs only on a disposable runner
- deployment-nas (win32): Needs cifs/nfs/nfsd kernel modules on the Docker host; runs on a GitHub runner
- deployment-nas (linux): Needs cifs/nfs/nfsd kernel modules on the Docker host; runs on a GitHub runner
- deployment-ha (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-power (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-power (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-operations (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-operations (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-three (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-three (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-containers (linux): Linux-host Compose (bind-mount ownership) runs only on GitHub Actions; the Windows lane covers Docker Desktop
Covered by another lane:
- deployment-stand (win32): The two-site stand of Linux systemd hosts runs in the linux-system lane
- docs (linux): The documentation site does not depend on the platform; the Windows lane builds it
- security (linux): npm audit of the same lockfile runs in the Windows lane
- large-full (linux): The 5 GiB transfer runs once, in the Windows lane
- large-multipart (linux): The 5 GiB multipart transfer runs once, in the Windows lane
Candidate acceptance
Arkvory local CI: PASSED
Profile release, commit eb80cc3c4b9033f0555263ca92bc736d3da13eb9.
Host: Windows_NT 10.0.22621, Node v24.13.0, Docker 29.4.3.
| Lane | Environment | Status | Gates |
|---|---|---|---|
| windows | windows-host | passed | deployment, deployment-containers, native-package |
| linux-system | linux-systemd-container | passed | deployment, deployment-services, native-install |
Not executed locally:
- deployment-services (win32): Installs Windows services; runs only on a disposable GitHub Actions runner
- native-install (win32): Installs the Windows package machine-wide; runs only on a disposable runner
- deployment-nas (win32): Needs cifs/nfs/nfsd kernel modules on the Docker host; runs on a GitHub runner
- deployment-nas (linux): Needs cifs/nfs/nfsd kernel modules on the Docker host; runs on a GitHub runner
- deployment-ha (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-power (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-power (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-operations (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-operations (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-three (win32): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-ha-three (linux): Needs KVM guests with DRBD 9 and fence_virsh; runs on a GitHub runner
- deployment-containers (linux): Linux-host Compose (bind-mount ownership) runs only on GitHub Actions; the Windows lane covers Docker Desktop
Covered by another lane:
- deployment-stand (win32): The two-site stand of Linux systemd hosts runs in the linux-system lane
- docs (linux): The documentation site does not depend on the platform; the Windows lane builds it
- security (linux): npm audit of the same lockfile runs in the Windows lane
- large-full (linux): The 5 GiB transfer runs once, in the Windows lane
- large-multipart (linux): The 5 GiB multipart transfer runs once, in the Windows lane