[Feature] Add annotation to trigger contiguous slot compaction on a Redkey cluster

Open
  • Is something wrong?
#68 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go, kubernetes, redis
Domain
databases, devops, infrastructure

Research direction

Start at the Redkey CR annotation handling and the operator/Robin slot-assignment paths, comparing them with the initial cluster layout and existing scaling or upgrade coordination. Done means the compact-slots value triggers one resumable migration using CLUSTER SETSLOT, records observable progress and completion, handles canonical layouts and concurrency, and updates the operator guide and CR reference.

Written by the indexing model from the issue text.

Description

enhancement
Feature description

Add annotation to trigger contiguous slot compaction on a Redkey cluster

Context

Redkey Robin now correctly recovers a Redkey cluster when pods are recreated
while scaling or upgrade operations are in progress. The cluster ends up
well-formed and balanced (each node owns a fair share of the 16384 hash slots).

However, after such a recovery the slot-to-node distribution is not
contiguous the way it is on a freshly created cluster. Slots owned by a node
may be scattered across several non-adjacent ranges instead of a single clean
range per node.

This is not a functional problem — Redis keeps working correctly regardless
of how slots are laid out. But it becomes a problem for RDB-based data copy
workflows: when copying RDB files from one cluster to another, both clusters
must share the same slot distribution. A fragmented layout breaks that
assumption and makes file-level RDB copies unusable.

Proposal

Introduce an annotation on the Redkey CR that instructs the
operator/Robin to perform a slot compaction: reassign hash slots so that
each node owns a single contiguous range, matching the layout a freshly created
cluster would have.

Proposed annotation: redkey.inditex.dev/compact-slots

  • The operation is one-shot (an imperative trigger, not desired state).
  • Suggested value: a timestamp or monotonic token (e.g. RFC3339). Applying the
    annotation with a new value re-triggers compaction.
  • The operator records the last processed value (e.g. in status) so an
    unchanged annotation does not repeatedly trigger the operation.
Expected behavior
  1. User sets redkey.inditex.dev/compact-slots: "<timestamp>" on the Redkey CR.
  2. The operator/Robin plans a target layout of contiguous slot ranges,
    deterministically distributed across the current master nodes (same rule
    used at initial cluster creation).
  3. Slots are migrated to reach that target layout using CLUSTER SETSLOT /
    slot migration, moving data as needed.
  4. Once complete, the cluster has a homogeneous, contiguous slot distribution
    identical to a freshly created cluster of the same topology.
  5. The operator marks the annotation value as processed to avoid re-running.
Constraints & considerations
  • Compaction migrates real data between nodes and can be I/O intensive; it
    should run as a controlled, observable operation and be safe to interrupt
    (idempotent / resumable).
  • Must be mutually exclusive with, or safely queued behind, in-flight scaling
    and upgrade operations.
  • Should be a no-op if the cluster is already in the canonical contiguous
    layout.
  • Behavior for clusters with replicas: only master slot ownership is affected;
    replicas follow their masters.
  • Emit events / status conditions and metrics so operators can observe
    progress and completion.
Out of scope
  • Automatic/periodic compaction. This is an explicit, user-triggered action.
  • Changing the initial slot-assignment algorithm.
Acceptance criteria
  • Annotation redkey.inditex.dev/compact-slots is recognized on the Redkey CR.
  • Setting a new value triggers exactly one compaction.
  • After completion, each master owns a single contiguous slot range matching
    the freshly-created-cluster layout.
  • Operation is safe when concurrent scaling/upgrade is requested (queued or
    rejected with a clear condition).
  • No-op when the layout is already canonical.
  • Progress/outcome is observable via events, status conditions, and metrics.
  • Documentation updated (operator guide + CR reference).
Use case or motivation

No response

Would you like to work on this?

Yes, I'd like to open a PR

Dominant language
Go
Stars
29
Forks
2
Avg merge
13h 32m
Merged PRs (30d)
16

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from InditexTech/redkey-operator

All issues in InditexTech/redkey-operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.