gpo.zugaina.org

Search Portage & Overlays:

app-metrics/victoria-metrics-cluster-bin

VictoriaMetrics cluster — prebuilt vminsert+vmselect+vmstorage

Screenshots

ChangeLog

commit ca9cf65a8b17673833029125c60d8a36748a6328
Author: Ramin Torabi <16882282+RaminTorabi@users.noreply.github.com>
Date: Fri Jun 5 20:40:29 2026 +0200

sanitize(victoria-metrics): drop private ansible playbook references

The public overlay must not name the private ansible-playbooks-gentoo
repo. The victoria-metrics pkg_postinst elog (which lands in the
operator email via the portage-elog forwarder) told users to "Tune
retention/listen/memory via the ansible victoriametrics role
(roles/victoriametrics in ansible-playbooks-gentoo)" - leaking the
private repo name and its internal layout into a public ebuild.

Replace with playbook-agnostic guidance: tune via a systemd drop-in
at /etc/systemd/system/victoria-metrics.service.d/ (standard,
public systemd knowledge; no private references).

Cleaned all five touch points across both the single-node and the
(hard-masked) cluster variants:
- victoria-metrics{,-bin} pkg_postinst elog
- victoria-metrics-bin src_install layout comment
- victoria-metrics-cluster{,-bin} src_install layout comment
- both files/victoria-metrics.service ExecStart comments

Overlay-wide grep for ansible/playbook now returns nothing. elog/
comment/service-comment changes do not touch ebuild metadata
variables, so md5-cache is unaffected. bash -n clean on all four
ebuilds.

commit 54dff7213f31b93af5f23d51a8ee17b89410ed10
Author: ami-gentoo weekly-verify (i-008ef8c4250c373c5) <16882282+RaminTorabi@users.noreply.github.com>
Date: Sat May 30 04:05:22 2026 +0000

weekly-verify: stamp 1 ebuilds (2026-05-30)

Stamped:
- app-metrics/victoria-metrics-cluster-bin-1.143.0

commit f55501a16bfd8d033ad935bcb6b0329c9573fa1f
Author: Ramin Torabi <16882282+RaminTorabi@users.noreply.github.com>
Date: Sun May 24 08:43:40 2026 +0200

feat(app-metrics): add victoria-metrics-cluster{,-bin} (hard-masked)

VictoriaMetrics cluster mode is the horizontally-scalable variant of
the database, decomposing the single-node binary into three services
(vminsert, vmselect, vmstorage) that communicate over RPC and follow
a shared-nothing architecture.

Two new sibling packages mirror the single-node convention:

- app-metrics/victoria-metrics-cluster: source build from the
parallel v$-cluster upstream tag (vendor/ ships, fully
offline build, -mod=vendor).

- app-metrics/victoria-metrics-cluster-bin: prebuilt repackaging of
the upstream victoria-metrics-linux-amd64-v$-cluster.tar.gz
release artifact (three statically-linked Go binaries, install
completes in seconds).

Both ship three systemd unit files (vmstorage.service,
vminsert.service, vmselect.service) with sane single-host defaults:
loopback storageNode wiring, separate http listen ports (8480/8481/
8482), separate RPC ports (8400/8401), data path under
/var/lib/victoria-metrics/cluster/ to avoid collision with the
single-node sibling's /var/lib/victoria-metrics/ root.

Both reuse the existing acct-{user,group}/victoria-metrics service
account. RDEPEND uses an git -P add app-metrics/victoria-metrics-cluster app-metrics/victoria-metrics-cluster-bin metadata/md5-cache/app-metrics/victoria-metrics-cluster-1.143.0 metadata/md5-cache/app-metrics/victoria-metrics-cluster-bin-1.143.0 profiles/package.mask README.md && git -P status -s blocker between cluster and cluster-bin
(same as the single-node pair) but intentionally NOT against the
single-node siblings - the binary names and unit names are
non-overlapping, so Portage doesn't need to enforce uniqueness.

Both packages are hard-masked in profiles/package.mask. Cluster
mode is shipped for completeness and to give a clean upgrade path
if a fleet ever outgrows single-node, but the single-node sibling
is the recommended default for any deployment below ~1M samples/sec
(simpler to operate, ~3x less memory).