spikerj/spikersoft-issues
1
0
Fork 0
Code Issues 196 Pull Requests Actions Packages Projects Releases Wiki Activity

infra: pin redis/redis-stack-server to a digest; plan migration to redis:8 #462

New Issue
Closed
opened 2026-07-08 21:28:50 +00:00 by spikerj · 3 comments
spikerj commented 2026-07-08 21:28:50 +00:00
Owner
Copy Link
Copy Source

Follow-up flagged in #444 (notes section).

Production (spikersoft-infrastructure/redis-cluster/docker-stack.yml) pins redis/redis-stack-server:latest — a floating tag. Two actions:

  1. Pin to a digest so the 6-node cluster doesn't silently change under us on node restarts/re-pulls.
  2. Plan the redis:8 migration: redis-stack-server is on a deprecation path; redis:8 bundles the modules we use (Search, JSON, TimeSeries, Bloom) in core.

When the image moves, update in lockstep (per SpikerSoft.Tests.Integration/README.md): RedisFixture.RedisImage, RedisClusterTestFixture.RedisImage, docker-compose.test.yml, and the infra stack file — the test fixtures exist to stay prod-parity.

Repos: spikersoft-infrastructure (primary), spikersoft-backend (test fixtures).

Follow-up flagged in #444 (notes section). Production (`spikersoft-infrastructure/redis-cluster/docker-stack.yml`) pins `redis/redis-stack-server:latest` — a floating tag. Two actions: 1. **Pin to a digest** so the 6-node cluster doesn't silently change under us on node restarts/re-pulls. 2. **Plan the redis:8 migration**: redis-stack-server is on a deprecation path; `redis:8` bundles the modules we use (Search, JSON, TimeSeries, Bloom) in core. When the image moves, update in lockstep (per SpikerSoft.Tests.Integration/README.md): `RedisFixture.RedisImage`, `RedisClusterTestFixture.RedisImage`, `docker-compose.test.yml`, and the infra stack file — the test fixtures exist to stay prod-parity. Repos: spikersoft-infrastructure (primary), spikersoft-backend (test fixtures).
spikerj commented 2026-07-09 00:32:08 +00:00
Author
Owner
Copy Link
Copy Source

Digest pinning is done (action 1). Chosen digest — the manifest-list digest of redis/redis-stack-server:latest as of 2026-07-08, covering linux/amd64 and linux/arm64:

redis/redis-stack-server:latest@sha256:798ab84d9f266936b034ab11c4d04a2b8e4b441884c5aa7d17ac951eefdf742a

(Per-platform manifests: amd64 sha256:39adcbb0..., arm64 sha256:75cb09fe.... This is the content prod nodes already run, so redeploys are a no-op image-wise.)

Pinned in lockstep across all four locations:

  • spikersoft-backend PR #190 (merged): RedisFixture.RedisImage, RedisClusterTestFixture.RedisImage, docker-compose.test.yml + README lockstep note — full integration suite green against the pinned image (143 passed / 3 skipped, 4m24s).
  • spikersoft-infrastructure PR #14 (merged): all 7 references in redis-cluster/docker-stack.yml (6 nodes + cluster_initiator).

redis-cluster/backup.yml was left untouched — per spikerj it's a dead experiment, not a live deployment target.

Action 2 (redis:8 migration) is being attempted as part of the spikersoft-issues#465 coverage effort: redis:8 bundles Search/JSON/TimeSeries/Bloom in core, so the four --loadmodule /opt/redis-stack/lib/*.so lines drop out of the cluster fixture, compose file, and stack file. The integration suite (FT.SEARCH KNN under RESP3, Redis.OM round-trip, cluster health) is the validation gate; findings will be reported here either way. Prod redeploy/rollout planning stays with this ticket.

Digest pinning is done (action 1). Chosen digest — the manifest-list digest of `redis/redis-stack-server:latest` as of 2026-07-08, covering linux/amd64 and linux/arm64: ``` redis/redis-stack-server:latest@sha256:798ab84d9f266936b034ab11c4d04a2b8e4b441884c5aa7d17ac951eefdf742a ``` (Per-platform manifests: amd64 `sha256:39adcbb0...`, arm64 `sha256:75cb09fe...`. This is the content prod nodes already run, so redeploys are a no-op image-wise.) Pinned in lockstep across all four locations: - spikersoft-backend PR #190 (merged): `RedisFixture.RedisImage`, `RedisClusterTestFixture.RedisImage`, `docker-compose.test.yml` + README lockstep note — full integration suite green against the pinned image (143 passed / 3 skipped, 4m24s). - spikersoft-infrastructure PR #14 (merged): all 7 references in `redis-cluster/docker-stack.yml` (6 nodes + `cluster_initiator`). `redis-cluster/backup.yml` was left untouched — per spikerj it's a dead experiment, not a live deployment target. Action 2 (redis:8 migration) is being attempted as part of the spikersoft-issues#465 coverage effort: redis:8 bundles Search/JSON/TimeSeries/Bloom in core, so the four `--loadmodule /opt/redis-stack/lib/*.so` lines drop out of the cluster fixture, compose file, and stack file. The integration suite (FT.SEARCH KNN under RESP3, Redis.OM round-trip, cluster health) is the validation gate; findings will be reported here either way. Prod redeploy/rollout planning stays with this ticket.
spikerj commented 2026-07-09 00:50:36 +00:00
Author
Owner
Copy Link
Copy Source

redis:8 migration (action 2) is done in code, validated by the integration suite:

  • spikersoft-backend PR #191 (merged): fixtures → redis:8@sha256:2838d5524559494f6f1cd66e97e76b200d64a633a8614200620755ed395daf32 (v8.8.0). RedisFixture is an image swap only; the cluster fixture and docker-compose.test.yml keep explicit --loadmodule (they bypass the entrypoint) with paths moved to /usr/local/lib/redis/modules. Full suite: 143 passed / 3 skipped, 4m47s.
  • spikersoft-infrastructure PR #15 (merged): all 7 stack references → same digest, all --loadmodule lines dropped (the redis:8 entrypoint injects them automatically for redis-server commands — verified against the image's docker-entrypoint.sh and MODULE LIST with a command override).

The suite caught a real prod bug: RediSearch 8.x renamed the missing-index error to SEARCH_INDEX_NOT_FOUND Index not found: <name>. RedisVectorIndexInitializationService (and three other call sites sniffing the old Unknown index name/no such index wording) would have treated "index missing" as a hard failure on redis:8 and never created the vector index — silently degrading vector search to the in-memory fallback. Fixed in PR #191; deploy the backend before rolling the cluster image.

Remaining for this ticket = prod rollout only: rolling redeploy (replicas first; engine goes 7.4-era → 8.8.0, no image rollback after nodes persist under the new version), then MODULE LIST / FT._LIST spot checks. Leaving the ticket open for that.

redis:8 migration (action 2) is done in code, validated by the integration suite: - **spikersoft-backend PR #191 (merged)**: fixtures → `redis:8@sha256:2838d5524559494f6f1cd66e97e76b200d64a633a8614200620755ed395daf32` (v8.8.0). `RedisFixture` is an image swap only; the cluster fixture and `docker-compose.test.yml` keep explicit `--loadmodule` (they bypass the entrypoint) with paths moved to `/usr/local/lib/redis/modules`. Full suite: 143 passed / 3 skipped, 4m47s. - **spikersoft-infrastructure PR #15 (merged)**: all 7 stack references → same digest, all `--loadmodule` lines dropped (the redis:8 entrypoint injects them automatically for `redis-server` commands — verified against the image's `docker-entrypoint.sh` and `MODULE LIST` with a command override). **The suite caught a real prod bug**: RediSearch 8.x renamed the missing-index error to `SEARCH_INDEX_NOT_FOUND Index not found: <name>`. `RedisVectorIndexInitializationService` (and three other call sites sniffing the old `Unknown index name`/`no such index` wording) would have treated "index missing" as a hard failure on redis:8 and never created the vector index — silently degrading vector search to the in-memory fallback. Fixed in PR #191; **deploy the backend before rolling the cluster image**. Remaining for this ticket = prod rollout only: rolling redeploy (replicas first; engine goes 7.4-era → 8.8.0, no image rollback after nodes persist under the new version), then `MODULE LIST` / `FT._LIST` spot checks. Leaving the ticket open for that.
spikerj commented 2026-07-11 23:26:29 +00:00
Author
Owner
Copy Link
Copy Source

Resolved — both actions done and exceeded: digest pinning in spikersoft-backend PR #190 + spikersoft-infrastructure PR #14 (merged), and the redis:8 migration itself (not just the plan) landed in backend PR #191 + infra PR #15 (merged), keeping fixtures and prod in lockstep. Closing.

Resolved — both actions done and exceeded: digest pinning in spikersoft-backend PR #190 + spikersoft-infrastructure PR #14 (merged), and the redis:8 migration itself (not just the plan) landed in backend PR #191 + infra PR #15 (merged), keeping fixtures and prod in lockstep. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#462