Skip to content

Arkvory 0.5.0

Latest

Choose a tag to compare

@Feargin Feargin released this 15 Oct 15:00
eb80cc3

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 configure and cluster-*.
    • 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_URL and ARKVORY_FLEET_LAG_ALERT configure 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, bulk and background. Strategies: ordered, smallest-first and shared.
    • 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.
  • Waiting instead of failing. The SDK and arkvoryctl wait when the server is busy (503 busy, 429 with Retry-After) and do not spend their retry budget on it.
    • --wait-limit and waitLimitMs cap the wait.
    • --not-before and --not-after (notBefore/notAfter in 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/mirrors is 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_conflicts and the alert ArkvoryMirrorConflicts.

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-node and cluster-release never 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 run upgrade --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 .deb on 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