Helm Action Preconditions by labelSelector

[Uburro]

Summary

Add optional checks before Helm install and upgrade actions. For example,
helm-controller can watch Nodes with the label node-pool=apps and wait until
the number of ready Nodes reaches a user-defined minimum.
Users do not need to change the chart. Waiting does not count as a failed Helm
attempt. Releases without these checks work as before.

Motivation

A cluster can have several node groups. Some applications need Nodes from a
specific group before they can be deployed. Those Nodes may still be starting
when Flux begins an install or upgrade. The Helm action can then time out, and
users have to set a high retry count to wait for the Nodes.

Users should be able to select a node group by label and set how many Nodes must
be ready. Flux should wait before starting Helm, without using up Helm retries.
Node names can change during replacement, so a fixed name is not enough.

Today, HelmRelease dependsOn can only refer to other HelmReleases.
healthCheckExprs checks resource health during Helm waiting, not before
an action starts.

The new check must run before each upgrade, including upgrades caused by chart
or values changes without a change to the HelmRelease itself.

Goals

• Find Nodes or other resources by name or label selector.
• Set how many matching resources must be ready before an action starts.
• Watch node groups and wait without needing a high Helm retry count.
• Use CEL, a language for writing checks that return true or false.
• Set install and upgrade checks separately.
• Show why an action is waiting, without using up Helm retries.

Non-Goals

• Keep a Node ready for the whole action or change Pod scheduling.
• Stop rollback, uninstall, or separate drift correction.
• Replace dependsOn or health checks after an action.

Proposal

A user adds preconditions: checks that must pass before an action starts.
Each check uses a name or label selector and gives a CEL expression.
The user sets minReady, the minimum number of matching resources that must
pass the expression. Other matches may be unready. An empty result does not
pass. If several checks are set, each must reach its own minimum.

For example, one check can require two ready Nodes in the apps group and
another can require one in the storage group. Extra ready Nodes in one group
do not replace missing ready Nodes in the other group.

The controller watches resource changes and queues a new check without keeping
a worker busy. It also checks again at regular intervals. Once all
checks pass, Helm runs as usual. A Node may become unready after a check.
This feature cannot guarantee readiness during the whole action.

API and example

Add optional lists at .spec.install.preconditions and
.spec.upgrade.preconditions. Each entry has these fields:

Field	Meaning
apiVersion, kind	Required fields that identify the resource type, such as v1 and Node.
name	Select one resource by its exact name. Use either name or labelSelector.
labelSelector	Select resources using Kubernetes matchLabels or matchExpressions. Use either labelSelector or name.
namespace	Optional. Defaults to the release's target namespace. Omit it for resources such as Nodes that have no namespace.
minReady	Optional positive integer. Defaults to 1. The number of matching resources that must pass readyExpr.
readyExpr	Required CEL expression, checked for each match. A resource counts as ready when it returns true.

Allow up to 16 checks per action and 4,096 characters per expression.
The expression defines readiness; there is no extra automatic readiness check.
Require exactly one of name or labelSelector. A selector must contain at
least one label rule. Validate it using the standard Kubernetes
[label selector rules][label-selectors]. Each check uses one resource kind;
use separate checks for different kinds.
Reject minReady values below 1. With name, it must be 1 because only one
resource can match. With a selector, a count below minReady means waiting,
even if all current matches are ready. Count each resource once per check;
do not add results from earlier checks in time.

This example waits for two ready Nodes with node-pool=apps before both install
and upgrade. Zero or one ready Node is not enough. The repository and
ServiceAccount must already exist.

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: my-app
  namespace: apps
spec:
  interval: 10m
  serviceAccountName: my-app-reconciler
  chart:
    spec:
      chart: my-app
      version: "1.2.3"
      sourceRef:
        kind: HelmRepository
        name: my-repository
  install:
    preconditions:
      - apiVersion: v1
        kind: Node
        labelSelector:
          matchLabels:
            node-pool: apps
        minReady: 2
        readyExpr: >-
          has(dep.status) && has(dep.status.conditions) &&
          dep.status.conditions.exists(c,
            c.type == 'Ready' && c.status == 'True')
  upgrade:
    preconditions:
      - apiVersion: v1
        kind: Node
        labelSelector:
          matchLabels:
            node-pool: apps
        minReady: 2
        readyExpr: >-
          has(dep.status) && has(dep.status.conditions) &&
          dep.status.conditions.exists(c,
            c.type == 'Ready' && c.status == 'True')