Mirrors/flux2
1
0
Fork 0
mirror of synced 2026-02-06 19:05:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Explain the evaluation logic based on conditions

Browse Source 
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
This commit is contained in:
Stefan Prodan
2025-01-17 15:11:21 +02:00
parent 6f6d3fb269
commit 74d748f547
1 changed files with 23 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
rfcs/0000-custom-health-checks/README.md
View File

@@ -33,8 +33,8 @@ condition to know if the certificate has been issued or not before looking at th
In order to provide a generic solution for custom resources, that would not imply
writing a custom `kstatus` reader for each CRD, we need to provide a way for the user
to express the conditions that need to be met in order to determine the status.
And we need to do this in a way that is flexible enough to cover all possible use cases,
without having to change Flux source code for each new use case.
It should be done in a way that is flexible enough to cover all possible use cases,
without having to change Flux source code for each new CRD.
### Goals
@@ -120,7 +120,7 @@ To help users define custom health checks, we will provide on the [fluxcd.io](ht
website a library of custom health checks for popular custom resources.
The Flux community will be able to contribute to this library by submitting pull requests
to the `fluxcd/website` repository.
to the [fluxcd/website](https://github.com/fluxcd/website) repository.
### User Stories
@@ -176,7 +176,7 @@ Example for `Cluster`:
We need an expression language that is flexible enough to cover all possible use
cases, without having to change Flux source code for each new use case.
An alternative that have been considered was to use `CUE` instead of `CEL`.
An alternative that has been considered was to use `CUE` instead of `CEL`.
`CUE` lang is a more powerful expression language, but given the fact that
Kubernetes makes use of `CEL` for CRD validation and admission control,
we have decided to also use `CEL` in Flux in order to be consistent with
@@ -217,6 +217,22 @@ type CustomHealthCheck struct {
}
```
If a CEL expression evaluation results in an error, for example looking for a field that does not exist,
the health check will fail. Users will be encouraged to test their expressions
in the [CEL Playground](https://playcel.undistro.io/). Here is where the community maintained
[library](#custom-health-check-library) will be super useful as some of the expressions might be complex.
The `InProgress` expression is optional, when not specified the controller will determine
if the resource is in progress if both `Failed` and `Current` evaluate to `false`.
Moreover, if the `InProgress` expression is not specified and the custom resource has a
`.status.observedGeneration` field, the controller with compare it with the `.metadata.generation`
field to determine if the resource is in progress.
The `Failed` expression is optional, when not specified the controller will keep evaluating the
`Current` expression until it returns `true`, and will give up after the timeout is reached.
Users will be encouraged to provide a `Failed` expression to avoid staling the reconciliation
loop until the timeout is reached.
### Introduce a generic custom status reader
We'll Introduce a `StatusReader` that will be used to compute the status
@@ -274,7 +290,7 @@ func genericConditions(kind string, exprs map[string]string) func(u *unstructure
// Use CEL to evaluate the expression
result, err := cel.ProcessExpr(expr, obj)
if err != nil {
return nil, err
// handle error
}
switch statusKey {
case status.CurrentStatus.String():
@@ -285,6 +301,8 @@ func genericConditions(kind string, exprs map[string]string) func(u *unstructure
// If the expression evaluates to true, we return the reconciling status
}
}
// If none of the expressions evaluate to true, we return the reconciling status
}
}
````