Places redis's directories (state = the assignment's root, grants and data placed, config/secret/receives/grants as ${dir:…}) instead of /services/redis/data and /var/lib/redis-module. Data and config are owned 999:1000, the image's redis user and group, which already own ace's data.
Pins the 7.4.11-alpine build ace runs (built 2026-09-17). The old pin was the same version but an older build.
No machine has it assigned today, so nothing changes anywhere.
For ace, the plan is to retire HAL's redis rather than migrate it. Its keyspace is empty, it has no client connections, and nothing in the catalogue requires redis-cache. The data directory (20 KB) is archived, not deleted. This manifest is what gets assigned if a consumer ever needs it.
Verified: the catalogue tests pass with MESH_CATALOGUE set to this tree, and the declaration composes for ace under /var/lib/redis. A throwaway run of the pinned image with a 0600 999:1000 config: unauthenticated PING gets NOAUTH, authenticated SET/GET works, appendonly is on, and the process runs as redis.
Places redis's directories (state = the assignment's root, grants and data placed, config/secret/receives/grants as `${dir:…}`) instead of /services/redis/data and /var/lib/redis-module. Data and config are owned 999:1000, the image's redis user and group, which already own ace's data.
Pins the 7.4.11-alpine build ace runs (built 2026-09-17). The old pin was the same version but an older build.
No machine has it assigned today, so nothing changes anywhere.
For ace, the plan is to **retire** HAL's redis rather than migrate it. Its keyspace is empty, it has no client connections, and nothing in the catalogue requires `redis-cache`. The data directory (20 KB) is archived, not deleted. This manifest is what gets assigned if a consumer ever needs it.
Verified: the catalogue tests pass with `MESH_CATALOGUE` set to this tree, and the declaration composes for ace under /var/lib/redis. A throwaway run of the pinned image with a 0600 999:1000 config: unauthenticated PING gets NOAUTH, authenticated SET/GET works, appendonly is on, and the process runs as redis.
The manifest stated /services/redis/data and /var/lib/redis-module - novox's
old layout, paths no definition may carry (ADR 0112). State is now the
assignment's root, grants and data are placed, and the config file, the
secret file, receives and grants all name them as ${dir:...}. Paths inside
the sidecar are its own view and are unchanged.
The data directory and config are owned 999:1000: the image's redis user is
uid 999 in gid 1000 (checked in both builds), which is who owns ace's data
today; 999:999 named a group the image does not use.
Image pinned to the 7.4.11-alpine build ace runs (2026-09-17); the old pin was
the same version, built in August. Older-than-running is never the pin.
Nothing is assigned it anywhere today, so no machine changes.
Verified: catalogue tests pass with MESH_CATALOGUE on this tree; the
declaration composes for ace with every path under /var/lib/redis. The pinned
image ran as a throwaway with a 0600 999:1000 config and a 0700 data dir:
unauthenticated PING is refused (NOAUTH), authenticated SET/GET works,
appendonly is on, the server runs as redis.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Places redis's directories (state = the assignment's root, grants and data placed, config/secret/receives/grants as
${dir:…}) instead of /services/redis/data and /var/lib/redis-module. Data and config are owned 999:1000, the image's redis user and group, which already own ace's data.Pins the 7.4.11-alpine build ace runs (built 2026-09-17). The old pin was the same version but an older build.
No machine has it assigned today, so nothing changes anywhere.
For ace, the plan is to retire HAL's redis rather than migrate it. Its keyspace is empty, it has no client connections, and nothing in the catalogue requires
redis-cache. The data directory (20 KB) is archived, not deleted. This manifest is what gets assigned if a consumer ever needs it.Verified: the catalogue tests pass with
MESH_CATALOGUEset to this tree, and the declaration composes for ace under /var/lib/redis. A throwaway run of the pinned image with a 0600 999:1000 config: unauthenticated PING gets NOAUTH, authenticated SET/GET works, appendonly is on, and the process runs as redis.The manifest stated /services/redis/data and /var/lib/redis-module - novox's old layout, paths no definition may carry (ADR 0112). State is now the assignment's root, grants and data are placed, and the config file, the secret file, receives and grants all name them as ${dir:...}. Paths inside the sidecar are its own view and are unchanged. The data directory and config are owned 999:1000: the image's redis user is uid 999 in gid 1000 (checked in both builds), which is who owns ace's data today; 999:999 named a group the image does not use. Image pinned to the 7.4.11-alpine build ace runs (2026-09-17); the old pin was the same version, built in August. Older-than-running is never the pin. Nothing is assigned it anywhere today, so no machine changes. Verified: catalogue tests pass with MESH_CATALOGUE on this tree; the declaration composes for ace with every path under /var/lib/redis. The pinned image ran as a throwaway with a 0600 999:1000 config and a 0700 data dir: unauthenticated PING is refused (NOAUTH), authenticated SET/GET works, appendonly is on, the server runs as redis.