feat(redis): size the Sentinel pods separately from Redis - #4832

What this PR does

The Redis application renders spec.sentinel.resources from the same resources/resourcesPreset pair as the Redis pods. Every instance runs three Sentinels, so it reserves three extra copies of a Redis replica's memory for processes that hold only their configuration and the failover state. The dataset that drives the Redis sizing never reaches a Sentinel.

On our Cozystack v1.6.4 staging cluster, an HA Redis on t1.nano reserves 3 x 128Mi for its Sentinels. The VPA recommender (recommendation mode only) gives an uncapped target of 16Mi for the sentinel container. On a u1.small instance the same three Sentinels would reserve 3 x 4Gi.

This PR adds an optional sentinel block with the same two keys the top level has:

resourcesPreset: u1.small
sentinel:
  resources:
    cpu: 100m
    memory: 64Mi
  # resourcesPreset: t1.nano

Resolution rules:

• sentinel empty (the default): the Sentinels keep the Redis sizing (resources + resourcesPreset). Existing instances therefore render exactly as before and an upgrade does not roll their Sentinels.
• sentinel.resourcesPreset set: the Sentinels use that preset. Explicit top-level resources are not carried over, since they were sized for the dataset.
• sentinel.resources set: it wins. Any key it leaves out is filled from sentinel.resourcesPreset, which falls back to resourcesPreset.
• The Sentinel WorkloadMonitor label workloads.cozystack.io/resource-preset now carries the preset the Sentinels actually use. The Redis WorkloadMonitor is unchanged.

Changes:

• values.yaml: new Sentinel parameters section (@typedef Sentinel, @param {Sentinel} [sentinel], default {}), reusing the existing Resources and ResourcesPreset types so the enum and quantity validation is the same as the top-level pair.
• templates/redisfailover.yaml: computes the Sentinel preset and resources once and uses them for spec.sentinel.resources and the Sentinel WorkloadMonitor label.
• README.md: generated table rows plus a short hand-written sentinel section next to resources and resourcesPreset.
• Generated: values.schema.json, api/apps/v1alpha1/redis/types.go (new Sentinel struct, ConfigSpec.Sentinel), api/apps/v1alpha1/redis/zz_generated.deepcopy.go, packages/system/redis-rd/cozyrds/redis.yaml.
• tests/sentinel_resources_test.yaml: 10 helm-unittest cases covering the rules above and an unknown preset being refused.

I chose not to change the default sizing. A smaller default (for example a fixed small preset for Sentinel) would save more for everyone, but it would also roll every instance's Sentinels and change what tenants are billed for on upgrade. If maintainers prefer that, it is a one-line follow-up on top of this change.

Testing done:

• make generate in packages/apps/redis with cozyvalues-gen v1.7.0 (the version pre-commit.yml installs); regenerated files committed.
• Deepcopy: controller-gen object v0.16.4 on api/apps/v1alpha1 (the last step of hack/update-codegen.sh), only the redis package changed; go build ./... and go vet ./redis/ pass in that module, go mod tidy leaves no diff. I could not run the full root make generate on my machine: code-generator v0.37.1 fails to parse the Go 1.27.1 standard library (math/rand/v2: method must have no type parameters), which is a host toolchain problem unrelated to this change. CI's codegen-drift job should confirm.
• make test in packages/apps/redis (helm-unittest v1.1.2): 58 passed. With the template change reverted, 4 of the new cases fail (the ones that set sentinel.*); the cases that pin today's behaviour pass both ways.
• Rendered output with no sentinel block is identical to main (all documents except the random-password Secret) for the defaults, resourcesPreset=u1.small, and explicit resources (cpu 1, memory 2Gi).

Backwards compatibility: purely additive. The field is optional with an empty default, existing instances render unchanged, and nothing rolls on upgrade. Clients that do not know the field are unaffected.

Screenshots

Not a UI change. The dashboard form gets a sentinel object from the schema like other nested parameters (e.g. tls).

Downstream repositories

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:
• cozystack/community - follow-up:

Trigger map walked against the diff: this adds a field to values.schema.json, so cozystack/terraform-provider-cozystack needs to model sentinel.resources / sentinel.resourcesPreset in its Redis resource. I will open that issue once this PR has a number and link it here; a draft is in FOLLOWUP-terraform-provider-redis-sentinel.md. The website page for redis is regenerated from README.md by the release bot (redis is in the website APPS list), so no manual follow-up there. Nothing else in the map is touched.

Release note

feat(redis): new optional `sentinel.resources` and `sentinel.resourcesPreset` parameters size the three Sentinel pods independently of the Redis pods. When unset, Sentinels keep the Redis sizing as before, so existing instances are unchanged.

Summary by CodeRabbit

• New Features
  • Added independent CPU and memory resource settings and sizing presets for Redis Sentinel pods.
  • When Sentinel-specific settings aren’t provided, Sentinel pods inherit Redis resource settings. Unspecified Sentinel resource values can use the Sentinel preset, which defaults to the Redis preset.
  • Added configuration documentation and validation for Sentinel resource settings.