[Feature] Apply Service override and PDB changes in place, without a cluster upgrade

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
go, kubernetes
Domain
backend, devops

Research direction

Start by locating DetectChanges, DetermineStatusTransition, handleConfigChange, and handleStandaloneConfigChange, then read the existing no-operation path and the ReconcileService / ReconcilePDB call sites. Add focused unit coverage for change detection and transitions, followed by an integration test that checks the Service labels and confirms no pod is deleted. Done means service and PDB only changes are applied without an upgrade in both cluster and standalone modes, while mixed changes still upgrade.

Written by the indexing model from the issue text.

Description

enhancement
Feature description
Feature description

Changes to spec.override.service or spec.pdb should be applied in place, by reconciling the Service / PodDisruptionBudget, and the config marked Applied, instead of moving the cluster to Upgrading.

Today DetectChanges reports any difference in Override or Pdb as HasKubernetesChanges, so DetermineStatusTransition returns Upgrading. Every upgrade path ends up applying these changes only through kubernetes.ReconcileService / kubernetes.ReconcilePDB; they never touch the StatefulSet pod template. The upgrade itself is not needed for them.

Proposal
  • Split the detection of Override changes:
    • override.statefulSet changes keep counting as HasKubernetesChanges, because they affect the pod template.
    • override.service changes and pdb changes go to a new category, e.g. HasInPlaceChanges.
  • In handleConfigChange (cluster) and handleStandaloneConfigChange (standalone), when the only changes are in-place changes (optionally together with auth and Robin changes, which are already handled without an operation):
    • call ReconcileService / ReconcilePDB;
    • mark the config Applied and keep the previous cluster status, as the existing "no cluster operation required" path does.
  • When in-place changes come together with changes that do require an operation, keep the current behaviour: the upgrade already reconciles the Service and PDB.
Use case or motivation

Adding a label to the Service, as platform tooling may require, currently triggers a full upgrade on every existing cluster:

  • Rolling N+1: extra nodes, slot migration and scale-down, just to update Service metadata.
  • Fast upgrade (ephemeral, replicasPerPrimary: 0, purgeKeysOnRebalance: true): handleFastUpgradeStart deletes all pods unconditionally, so all keys are lost, even though the pod template did not change.
Acceptance criteria
  • A config that only changes spec.override.service (metadata or spec) is applied without a status transition: the Service is updated and the config is Applied.
  • Same for a config that only changes spec.pdb.
  • Works for cluster and standalone modes.
  • Changes to spec.override.statefulSet, spec.labels, spec.annotations, image, resources, storage or Redis config still go through Upgrading.
  • Mixed changes (in-place + upgrade-requiring) still go through Upgrading, and the Service/PDB end up reconciled.
  • Unit tests for DetectChanges / DetermineStatusTransition, and an integration test checking that no pod is deleted and the Service gets the new labels.
Related

Independently of this, the fast upgrade could skip pods that already run the StatefulSet's update revision (as the rolling upgrade does with controller-revision-hash), so a change that does not affect the pod template never deletes pods. That could be a separate issue.

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
18
Forks
0
Avg merge
11h 16m
Merged PRs (30d)
11

Getting set up

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-robin

All issues in InditexTech/redkey-robin

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.