Make Brainstore rollout controls configurable

[Alexey Soldatchenko (soldatchenko)]

Brainstore readers, fast readers, and writers maintain local caches and can perform substantial startup and processing work. During an upgrade, deployments may need different trade-offs between rollout speed, available capacity, and the number of replacement pods starting at once.

The chart currently hardcodes the Deployment rollout behavior for all three Brainstore roles. This change exposes standard Kubernetes rollout controls so operators can tune each role for their environment.

What changes

• add independently configurable strategy, minReadySeconds, and progressDeadlineSeconds values for Brainstore readers, fast readers, and writers
• validate that each progress deadline is greater than its readiness dwell so invalid Deployments fail during Helm rendering
• render rolling-update settings only when the selected strategy is RollingUpdate
• preserve the prior rollout behavior for helm upgrade --reuse-values upgrades from chart releases that predate these settings
• document rollout-only scope, Recreate outages, mixed-version upgrade considerations, and provide a conservative one-at-a-time rollout example
• cover default, custom, reused pre-feature, invalid deadline, and Recreate rendering with unit tests

Upgrade impact

This change is backward-neutral for customers who do not configure the new values. The defaults preserve the effective behavior from earlier chart versions:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 100%
    maxUnavailable: 0
minReadySeconds: 0
progressDeadlineSeconds: 600

Upgrading the chart with existing values does not change Brainstore rollout pacing. These settings are outside the pod template, so this feature does not restart Brainstore pods by itself. Custom settings apply when a later image, configuration, resource, or other pod-template change triggers a rollout.

Why operators may tune this

• maxSurge limits the additional pods that can start during a rollout.
• maxUnavailable controls how much existing capacity Kubernetes may remove while replacing pods.
• minReadySeconds requires a replacement to remain Ready for a minimum period before Kubernetes considers it available and continues the rollout.
• progressDeadlineSeconds defines how long Kubernetes allows the Deployment to make progress and must be greater than minReadySeconds.

For example, a cache-heavy deployment can use maxSurge: 1, maxUnavailable: 0, and a longer minReadySeconds to bound simultaneous cache warm-up and processing pressure while preserving its desired available replicas. This intentionally makes the rollout slower and requires capacity for the configured surge.

These settings pace Deployment-managed rollouts. They do not create Brainstore PodDisruptionBudgets or protect against node drains, evictions, or failures. Slower rollouts also extend the mixed-version window, so operators should follow version-specific upgrade guidance and avoid combining image changes with incompatible storage-format changes.

Validation

• ./test.sh
  • 30 suites passed
  • 318 tests passed
  • AWS, Azure, GKE, and minimal chart rendering passed
  • strict Helm lint passed

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-04T15:53:15.365414Z	561aa0b	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "Codex (@codex) review" or "Codex (@codex) security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 561aa0ba99

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "Codex (@codex) review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "Codex (@codex) address that feedback".