mirror of
https://github.com/mulgadc/spinifex.git
synced 2026-10-15 09:01:31 +00:00
Josh Siviour
b0faa72428
* ci: benchmark Predastore across a real 3-node Spinifex env The nightly throughput job runs three s3d processes on loopback aliases on a single box against local NVMe, so nothing measures Predastore in the shape it ships in: three machines, with reads crossing a real NIC between hosts. This provisions a 3-node env the way the multi-node e2e job does, then hands its three gates to the existing harness through PERF_EXTERNAL_HOSTS. The harness skips its own start and stop and measures them directly, so the workloads and analysis are unchanged and the two numbers stay comparable. It runs on a systemd LAN runner rather than the ephemeral pool because a pool VM sits behind the geneve overlay at MTU 1408, which would put the runner's own network path inside the measurement. * ci: trigger the 3-node benchmark on its own branch for a first run A workflow_dispatch only resolves against the default branch, so this cannot be dispatched until it is merged. The push trigger is scoped to this branch and comes back out once the workflow is on dev. * fix: measure as the identity the provisioned cluster actually mints spx admin init generates a random access key pair at bootstrap and writes it to node1's ~/.aws/credentials, so the benchmark's built-in key is one this cluster has never heard of and every run died on the first CreateBucket. The pair is read and used inside a single step, the way e2e-ddil.yml does it: a step-level env: block is echoed verbatim into the run log, a shell variable is not. * ci: default the 3-node benchmark to the compare preset smoke was the right default while the pipeline was unproven. It is green now, and compare is what the nightly loopback run uses, so it is the preset whose numbers can be set beside it. * ci: make the cluster's ref a knob, pinned to v1.18.0 for one run The harness stays on this branch while the cluster is built from whatever ref is asked for, so an old release is measured with the same ruler as the current one. run-info.txt records the deployed ref rather than the harness checkout. The v1.18.0 default is temporary: a push event carries no dispatch inputs, and this cannot be dispatched until it is on dev. It comes back out after the run. * test: probe ranged GETs, which no workload here exercises Warp reads whole objects, so the throughput figures stay healthy while ranged GETs read the whole object per request. The probe reads the same boundary crossing range from a 64 MiB and a 256 MiB object: under read amplification the cost tracks object size, and otherwise the two match. Cluster ref is pinned to the fix branch for this run and comes back out after. * test: run the ranged GET probe against dev to prove it fails there A probe that has only ever been green proves nothing about the fix. Pointing the cluster at dev, which still has the defect, is the control that shows the probe detects it. The pin comes back out after. * ci: drop the branch push trigger and the cluster ref pin Both were scaffolding to run this before it existed on dev. The workflow is dispatch only again, and cluster_ref defaults to the branch under test.