You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When .spec.driftDetection.mode is set to warn or enabled, and the desired state of the HelmRelease is in-sync with the Helm release object in the storage, the controller will compare the manifest from the Helm storage with the current state of the cluster using a server-side dry-run apply.
Is it not a mistake? the HelmRelease drift-detection feature introduced in Flux 2.2 is, as far as I understand, based on k8s server-side dry-run but not on Server-Side Apply/SSA.
The text was updated successfully, but these errors were encountered:
Or is maybe the helm-controller running a SSA with "dry-run" request (towards the k8s API server) for each and every of the (rendered) manifests retrieved from the sh.helm.release.v1.<name-of-Helm-release>.v<latest Helm release revision> k8s Secret API object ... and so discarding manual modifications applied on fields for which the rendered Helm charts manifests are not having any opinion?
Or is maybe the helm-controller running a SSA with "dry-run" request (towards the k8s API server) for each and every of the (rendered) manifests retrieved from the sh.helm.release.v1..v k8s Secret API object
Drift detection chapter in Flux HelmRelease documentation currently says:
Is it not a mistake? the HelmRelease drift-detection feature introduced in Flux 2.2 is, as far as I understand, based on k8s server-side dry-run but not on Server-Side Apply/SSA.
The text was updated successfully, but these errors were encountered: