Validates that ObjectLevelWorkloadIdentity feature gate is enabled
when default kubeconfig service account flags are set. This prevents
misconfiguration where lockdown flags are used without enabling
the required feature gate.
Signed-off-by: cappyzawa <cappyzawa@gmail.com>
Adds new controller flag to enforce ServiceAccount usage in
multi-tenant clusters where administrators need to lock down workload
identity access:
- --default-kubeconfig-service-account
This flag complements the existing --default-service-account flag to
provide multi-tenancy lockdown coverage for kubeconfig ServiceAccount
fields in the HelmRelease API.
Signed-off-by: cappyzawa <cappyzawa@gmail.com>
Update kustomize from v5.6.0 to v5.7.0 for consistency across
FluxCD components, aligning with the kustomize-controller
update that addresses issues with multiple $patch: delete
strategic merge patches in a single patch file.
Updated dependencies:
- sigs.k8s.io/kustomize/api v0.19.0 -> v0.20.0
- sigs.k8s.io/kustomize/kyaml v0.19.0 -> v0.20.0
Signed-off-by: cappyzawa <cappyzawa@gmail.com>
As described at https://go.dev/wiki/Deprecated, the `Deprecated` comments shall start a new paragraph. This way, the deprecation is also visible to other tools like staticcheck and vscode.
Signed-off-by: Martin Hoffmann <hoffimar@gmail.com>
Signed-off-by: Matheus Pimenta <matheuscscp@gmail.com>
(chore): adds commonAnnotations and commonLabels to kustomize
if applied, this commit will pass the common labels and annotations specified in postRenderers kustomization and which gets propagated to all resources
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): generates updated api-docs
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): adds common metadata to spec
HelmRelease postRenderer uses `CommonMetadata` struct from kustomize controller to have a common CRD specification usage across flux API types
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): update helm release post renderer
HelmRelease kustomize post renderer uses the CommonMetadata type from kustomize controller to propagate common labels and annotations across all resources. Labels are not propagated to `selector.matchLabels`
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): generates updated CRD and api docs
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): adds common metadata types
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): removes common metadata
removes the insertion of common metadata info in `Kustomize.Run()`
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): adds common-metadata types
this commit adds CommonMetadata to HelmRelease spec as an optional field and when used will run a helm postRenderer to add specified labels and annotations resources contained in helm template. The digest of common metadata is stored as ObservedCommonMetadataDigest in the resource status
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): common post-renderer
this commit combines common metadata rendering and origin labels rendering into common_renderer.go with re-usable methods for label transformer and annotation transformer. Precedence is given to origin labels rendering over common metadata rendering.
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): trigger upgrade on commonMetadata value changes
this commit ensures that when commonMetadata value has changed after install triggers an upgrade action to re-render the new commonMetadata values to the helm release. The digest of commonMetadata values are stored in .status.ObservedCommonMetadataDigest for release state out-of-sync detection.
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(fix): adheres to import ordering
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(fix): revert go mod updates
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): updates copyright headers
Co-authored-by: Stefan Prodan <stefan.prodan@gmail.com>
Signed-off-by: Abhijith Ravindra <137736216+abhijith-darshan@users.noreply.github.com>
(chore): adds copyright headers
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): updates copyright headers
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): keep go mod in sync with upstream/main
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): adds common metadata documentation
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
(chore): fix precedence of label application
This commit will ensure that OriginLabels run last so that it has a higher precedence over CommonMetadata.Labels
Signed-off-by: abhijith-darshan <abhijith.darshan@hotmail.com>
This change adds a new field called `disableTakeOwnership` to `.spec.install` and `.spec.upgrade`. The flag allows users to disable ignoring helm annotations and labels before taking ownership of existing resources during install and upgrade.
Signed-off-by: Kumar Mallikarjuna <kumarmallikarjuna.work@gmail.com>
When using Helm with both a values file and --set, the set will always
have precedence over the values.yaml. This allows specifying the normal
config inside a yaml file and specifying a secret outside that yaml via
--set.
When using flux, this normally works too (using inline values to specify
most of the config and a reference with targetPath to get a secret), but
if you want to overwrite a secret key inside an array the inline values
will always overwrite the whole array and the referenced secret key will
not appear at all.
By making sure that when you specify a targetPath it has precedence over
inline values it will be merged properly.
Signed-off-by: Ströger Florian <florian@florianstroeger.com>
The `Mark…` functions in the `conditions` package accept a format string and
(optional) arguments, just like `fmt.Printf` and friends.
In many places, the code passed an error message as the format string, causing
it to be interpreted as a format string by the `fmt` package. This leads to
issues when the message contains percent signs, e.g. URL-encoded values.
This PR adds a format string and shortens `err.Error()` to `err`, which yields
the same output.
This change is identical in principle to
fluxcd/source-controller#1529.
Signed-off-by: Florian Forster <fforster@gitlab.com>
Tools such as Bitnami's charts-syncer strip the `v` prefix from the
chart version so that the OCI artifact version differs from the
version defined in the chart's metadata. This leads to an error
similar to this returned from h-c:
```
artifact revision 1.14.5 does not match chart version v1.14.5
```
This commit makes h-c ignore a leading `v` prefix in either the chart
version of the OCI artifact tag.
Signed-off-by: Max Jonas Werner <max.werner@associmates.eu>
Move the post renderers digest set/update code from summarize() to
atomic release reconciler in order to update the observation only at the
end of a successful reconciliation. summarize() is for summarizing the
status conditions and is also called by all the other action
sub-reconcilers, which can update the post renderers digest observation
too early.
Updating the observed post renderers digest at the very end of a
reconciliation introduces an issue where a digest mismatch in
DetermineReleaseState() could result in the release to get stuck in a
loop as even after running an upgrade due to post renderers value, the
new observation isn't reflected immediately in the middle of atomic
reconciliation. This can be solved by checking post renderers digest
value only for new configurations where the object generation and the
ready status condition observed generations don't match, in other words
when the generation of a configuration has not be processed. This
assumes that an upgrade due to any other reason also takes into account
the post renderers value and need not be checked separately for the same
config generation.
Signed-off-by: Sunny <github@darkowlzz.space>
(cherry picked from commit 63f7a76319)
Move the post renderers digest set/update code from summarize() to
atomic release reconciler in order to update the observation only at the
end of a successful reconciliation. summarize() is for summarizing the
status conditions and is also called by all the other action
sub-reconcilers, which can update the post renderers digest observation
too early.
Updating the observed post renderers digest at the very end of a
reconciliation introduces an issue where a digest mismatch in
DetermineReleaseState() could result in the release to get stuck in a
loop as even after running an upgrade due to post renderers value, the
new observation isn't reflected immediately in the middle of atomic
reconciliation. This can be solved by checking post renderers digest
value only for new configurations where the object generation and the
ready status condition observed generations don't match, in other words
when the generation of a configuration has not be processed. This
assumes that an upgrade due to any other reason also takes into account
the post renderers value and need not be checked separately for the same
config generation.
Signed-off-by: Sunny <github@darkowlzz.space>
This implementation update `.status.ObervedPostRenderersDigest` after a
successful reconciliation if `spec.postRenderers` is not nil.
Changes to `spec.postRenderers` are detected for `deployed` releases.
`Failed` and `Uninstalled` releases are detected earlier in the
reconciliation process.
Signed-off-by: Soule BA <bah.soule@gmail.com>
The test case successfully upgrade with the same chart because version
is not computed the same way (12 digits of digest appended for
OCIRepository source).
Signed-off-by: Soule BA <bah.soule@gmail.com>
This commit add the oci artifact digest into the release observed
snapshot. This is used to later to add that value as an annotation.
Signed-off-by: Soule BA <bah.soule@gmail.com>
Update the Ready condition during drift correction to reflect the
current state of reconciliation. Without this, any previous Ready
condition value continues to persist on the object. If there was a
previous failure due to which Ready=False condition is present on the
object, the same value continues to persist if the atomic release
reconciliation enters a drift detection and correction loop. Resulting
in the status to show inaccurate state of the reconciliation.
Examples of two different scenarios that arise due to this issue:
- If a release without any dependency is installed, the status shows
Ready=True for InstallSucceeded reason. But right after the
installation, if a drift is detected the status continues to show the
same Ready=True value. There's no indication that a drift correction
is going on in the status. The events and logs do show that drift
correction is taking place. But it can be confusing to see positive
Ready value. Also, since the Ready condition message is copied for
Reconciling condition, Reconciling=True with a "Helm install
succeeded..." is seen.
- If a release depends on another release, and reconciliation results in
dependency not ready error at first, Ready=False condition is added on
the object. On subsequent runs, even when the dependencies are ready,
the Ready=False condition isn't updated, resulting in stale Ready
value until atomic release reconciliation completes. But if the atomic
reconciliation enters a drift detection and correction loop, the
Ready=False with dependency error persists in the status. This gives
the impression that something is wrong with dependency check but based
on the logs and events, the controller could be stuck in drift
detection and correction loop.
Updating the Ready condition during drift detection shows the current
state of reconciliation, avoiding the confusing scenarios described
above.
Signed-off-by: Sunny <github@darkowlzz.space>
If implemented this PR reintroduce events for some failling action
during the reconciliation process, related to the helmChart retrieval
and loading of chart and values.
Signed-off-by: Soule BA <bah.soule@gmail.com>
When the reconciliation begins, while fulfilling the prerequisites,
Ready=False condition for various reasons are added on the object. On
failure, this reason is persisted on the object. On a subsequent
reconciliation, when the failure is recovered, the Ready=False condition
is not updates until the atomic reconciliation reaches a conclusion.
During this period if the atomic reconciliation enters a retry loop due
to constant drift detection and correction, the stale Ready=False
condition with incorrect reason persists on the object. The Ready=False
message is also copied to Reconciling=True condition, resulting in an
incorrect depiction of what's actually happening.
For example, if previously the HelmRelease failed with dependency not
ready error, on a subsequent reconciliation, even after going past the
dependency check and returning from atomic reconciliation due to drift
detection and correction loop scenario, the Ready=False condition
continues to show the stale dependency not ready error.
In order to show more accurate status, the Ready=False conditions added
while fulfilling prerequisites can be removed once those checks have
succeeded, updating Ready=False to Ready=Unknown with "reconciliation in
progress" message. If the atomic reconciliation gets stuck in the drift
detection and correction loop with this, the Ready and Reconciling
conditons would show "reconciliation in progress". This should be a
better indicator of what's going on. The events and logs can be checked
to determine accurately what's causing the reconciliation to be
progressing for ever.
Signed-off-by: Sunny <github@darkowlzz.space>
This accidentally did not get `if`-wrapped in
eaa2a8c2fe, breaking the configuration
option to watch a single namespace, and thereby as by-effect the
breakage of sharding.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
As we are (still) not making use of conversion webhooks, new fields can
only be introduced by including them in all served API versions. As
otherwise conversion will fail.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Detect stall condition due to exhausted remediation retry right after
remediating. This helps return from AtomicRelease.Reconcile() with
proper stalled status condition and error. Without this, after
remediation, a stalled condition detection required a new
reconciliation, leaving the status of the object without any Reconciling
or Stalled condition.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
This configures a logger on the HTTP client used to load a Helm chart,
ensuring HTTP errors surface faster.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This adds back the support for overwriting the host name a chart is
downloaded from (again) using the `SOURCE_CONTROLLER_LOCALHOST`
environment variable.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
As the Kubernetes client used in tests is cache backed, it can take a
tiny bit of time for the client to actually notice the removal.
Wrapping in `Eventually` should address this.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This includes an update of Kustomize to v5.3.0.
- github.com/fluxcd/cli-utils to v0.36.0-flux.2
- github.com/fluxcd/pkg/runtime to v0.43.1
- k8s.io/utils to v0.0.0-20231127182322-b307cd553661
- sigs.k8s.io/kustomize/api to v0.16.0
- sigs.k8s.io/kustomize/kyaml to v0.16.0
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
- github.com/go-logr/logr to v1.3.0
- golang.org/x/net to v0.19.0
- golang.org/x/text to v0.14.0
- k8s.io/klog/v2 to v2.110.1
- k8s.io/utils to v0.0.0-20231127182322-b307cd553661
- sigs.k8s.io/structured-merge-diff/v4 to v4.4.1
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This test has shown to be a flake on multiple ocassions.
After running it locally a dozen of times, my conclusion is that the
time it takes for Kubernetes to shutdown a Pod may sometimes be a tiny
bit longer than anticipated by the current timeout.
Therefore, increase it to 5 minutes and provide more context on the
state of the namespace in case a timeout occurs.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Remediation can roll back to a version that matches with the next good
config. In such situation, release will be in-sync and no action will be
performed. The status conditions will continue to show Remediated=True
and Released=False. Check and remove stale Remediated condition and add
a Released=True condition with message constructed from the latest
release.
Introduce replaceCondition() to replaces target condition with a
replacement condition, retaining the transition time. This helps ensure
that the last transition time of releases don't change when a release is
marked from remediated to released.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
This propagates the reason a HelmChart is (likely) not ready to the
message of the Ready condition.
The goal of this is to make it easier for people to reason about a
potential failure that may be happening while retrieving the chart,
without having to inspect the HelmChart itself.
As at times, they may not have access (due to e.g. not being able to
access the namespace, while the controller is allowed to create the
object there), or are simply not aware of the fact that this object
is created by the controller for them.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
They have been deprecated for a long time, and should be scheduled for
removal to ensure they can be removed in the final `v2` release.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
When a Helm install or upgrade is performed, to prevent confusion due to
reporting a stale test result.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Due to the frequency, this would otherwise suppress other Kubernetes
Events which are more important. Especially when the `.spec.interval`
of the HelmRelease is set to a low value.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures that if there is no target to roll back to due to all of
them being in a failed state, the controller stalls instead of ending up
in a loop of upgrade attempts.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures that any unfulfilled dependencies for which we requeue do
not prematurely bump the observed generation by introducing typed
errors.
These typed errors ensure that the logic to bump the observed generation
can continue to be the same, while ignoring them just in time before
returning the final error.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures that on repetitive failures, the number of snapshots does
not grow indefinitely due to there not being any in a superseded or
deployed state.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This makes the controller actually take the
`reconcile.fluxcd.io/forceAt` and `reconcile.fluxcd.io/resetAt` into
account.
For `reconcile.fluxcd.io/resetAt`, this means that the failure counts on
the `HelmRelease` object are reset when the token value of the
annotation equals `reconcile.fluxcd.io/requestedAt`. Allowing the
controller to start over with attempting to install or upgrade the
release until the retries count has been reached again.
For `reconcile.fluxcd.io/forceAt`, this means that a one-off Helm
install or upgrade is allowed to take place even if the object is out of
retries, in a failed state where it should be remediated, or in-sync.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This introduces two new annotations:
- `reconcile.fluxcd.io/resetAt`: to reset the failure counts for a
`HelmRelease` object.
- `reconcile.fluxcd.io/forceAt`: to allow a one-off Helm install or
upgrade when the controller would otherwise do nothing (e.g. due to
being out of retries, in-sync, in a failed state, etc.)
Both annotations require the `reconcile.fluxcd.io/requestedAt`
annotation to be set at the same time, with the same token value.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures that the metadata labels and annotations Helm adds during
the creation of resources are included while diffing them.
As they are not part of the manifest but should be restored in case
they are e.g. removed or modified.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This changes the cluster drift correction behavior from performing a
Helm upgrade to performing create and patch API requests based on the
JSON Patch data.
Doing this is much lighter than performing a full release cycle, and
deals with the issue of Helm being unable to restore state of Custom
Resources without the `--force` flag being set. Which has unwanted
side-effects like forcing objects through a deletion/creation cycle.
After a drift correction attempt a Kubernetes Event is emitted, which
contains a summary of the created and patched resources, and a
collection of any (potential) errors.
As the goal is to restore state as best as we can, the drift correction
will be re-attempted until all resources have been restored to the
desired state.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This introduces a `--snapshot-digest-algo` flag to allow configuring a
different algorithm than SHA256.
This allows the user to for example configure `blake3`, which is
potentially faster (and less resource intensive) on modern hardware.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
These functions are no longer in use by the actual code base, while the
same outcome can be achieved by using `LastRelease` in combination with
`VerifyReleaseObject`.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This used to drive the logic behind the `v2beta1` API, but has now
become obsolete with the `action` sub-module as its successor.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This allows `DetermineReleaseState` to determine if the cluster state
has drifted from the manifest defined in the Helm storage. This allows
the atomic reconciler to determine if an upgrade should happen based
on the configuration of the `HelmRelease`.
If drift detection is `enabled` (or set to `warn`), it will report
drift via the controller logs and a Kubernetes Event. In addition, when
correction is enabled, it will instruct to perform a Helm upgrade to
correct the drift.
To summarize the detected drift in a compact message, summarize
utilities have been introduced to the `diff` package.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
The `Diff` action can be used to detect changes between the manifest
from a Helm release and the current cluster state.
Compared to the previous diff functionality, it allows for ignoring
specific fields in a resource using the newly introduced ignore rules
in the API.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This adds the option to enable drift detection for a specific
`HelmRelease` instance using `.spec.driftDetection.mode`.
Supported configurations are `enabled` (detect and correct), `warn`
(detect) and `disabled`.
In addition to this, it allows defining a set of ignore rules using
`.spec.driftDetection.ignore`. Which can be used to ignore (portions
of) a resource using JSON pointers and target selectors.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Helm v3.13.x includes a change which causes labels to be magically
set during writes to the storage, without persisting them to the
release object which is passed to the interface.
Because of this, at the time of observing the initial write to the
storage we would not see them, but once we are verifying them we would.
Causing the calculated digest to always differ, and making the
controller think the storage item had changed.
While I am of opinion it would be better for Helm to set the labels on
the release object as soon as they are persisted to the storage, the
only solution now for us is to ignore them.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
- github.com/fluxcd/cli-utils to v0.36.0-flux.1
- github.com/fluxcd/pkg/apis/event to v0.6.0
- github.com/fluxcd/pkg/apis/kustomize to v1.2.0
- github.com/fluxcd/pkg/apis/meta to v1.2.0
- github.com/fluxcd/pkg/runtime to v0.43.0
- github.com/fluxcd/pkg/ssa to v0.34.0
- github.com/fluxcd/pkg/testserver to v0.5.0
- github.com/go-logr/logr to v1.3.0
- github.com/google/go-cmp to v0.6.0
- github.com/hashicorp/go-retryablehttp to v0.7.5
- github.com/onsi/gomega to v1.30.0
- github.com/opencontainers/go-digest to v1.0.1-0.20231025023718-d50d2fec9c98
- github.com/opencontainers/go-digest/blake3 to v0.0.0-20231025023718-d50d2fec9c98
- golang.org/x/text to v0.14.0
- helm.sh/helm/v3 to v3.13.2
- k8s.io/api to v0.28.4
- k8s.io/apiextensions-apiserver to v0.28.4
- k8s.io/apimachinery to v0.28.4
- k8s.io/cli-runtime to v0.28.4
- k8s.io/client-go to v0.28.4
- k8s.io/kubectl to v0.28.4
- k8s.io/utils to v0.0.0-20231121161247-cf03d44ff3cf
- sigs.k8s.io/controller-runtime to v0.16.3
- sigs.k8s.io/kustomize/api to v0.15.0
- sigs.k8s.io/kustomize/kyaml to v0.15.0
- sigs.k8s.io/yaml to v1.4.0
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
- github.com/fluxcd/pkg/apis/kustomize to v1.2.0
- github.com/fluxcd/pkg/apis/meta to v1.2.0
- k8s.io/apiextensions-apiserver to v0.28.4
- k8s.io/apimachinery to v0.28.4
- sigs.k8s.io/controller-runtime to v0.16.3
- sigs.k8s.io/yaml to v1.4.0
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
We should actually add more of them now that the code base has grown (in
complexity). But this solves the issue for CI for now.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensure that when a chart object has a temporary `Ready=False`
state, the predicate will notice the change to `Ready=True` and
cause an enqueue request.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This allows the controller to be updated from `v2beta1` to `v2beta2`
without triggering a release to settle state.
It does this by looking at the previous successful release as recorded
for the `v2beta1` object, and if found, recording a snapshot for it in
the new `History` field of the status.
This feature can be disabled by setting the `AdoptLegacyReleases`
feature flag to `false`.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This allows users to delay updating their `apiVersion` declarations,
as the fields will be known in the previous version.
If we would not do this, the fields would get wiped when the `v2beta1`
resource is applied, potentially causing spurious upgrades.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures that certain UIs can continue to display information to
their users while they work on making better use of the new data
available in `v2beta2`.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
During tests, Helm logs a mixture of debug and timeout errors which
(unlike during install or upgrade) do not provide much useful
information about the reason of failure.
Given this, remove the logs from the output to reduce noise.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
As anything beyond ~3 releases has no real value to the controller
itself, while the time it takes to perform a release increases with
the number of releases kept in history.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
As persisting to the API server before an unexpected termination is not
feasible, allow a release to be unlocked without it being observed.
This has the potential result of interfering with a user running `helm`
by hand, but the further process should be capable of dealing with any
unexpected failure resulting from this.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This decouples the state determination from deciding which action to
take, making it easier to reason about the different types of state
and what action should be taken to drive it forward.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This can be used to reliable determine the active remediation strategy
which should be used. Including in edge cases where e.g. an uninstall
remediation is configured for upgrade failures.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
- Change the log-level of "action determination" to "debug".
- Set `Ready=Unknown` while working on an install or upgrade.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
We actually only care about the chart name or version changing, as we
assume proper (immutable) versioning by the publisher of the chart
(either the user, or the source-controller).
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This improves the reconciliation of an uninstall when the release has
already been uninstalled while `KeepHistory` has been set, by detecting
the (sadly non-typed) error Helm produces as desired state.
Avoiding certain edge-cases where for example a deleted HelmRelease
would end up in an irrecoverable loop of uninstall attempts, after
being remediated (using an uninstall) before the deletion request.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
As we are working with secondary state which we need to keep track of,
persisting the last state even when the context is canceled (due to
e.g. a controller shutdown) is important to improve the chances of
successfully being able to recover from any abrupt terminations.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
From `<namespace>/<name>.<version>` to `<namespace>/<name>.v<version>`,
to better resemble the internal name format of e.g. Helm storage
Secrets.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures the logs of the Kubernetes client used by Helm are
persisted to the log buffer, as they can contain important information
when an action times out.
In addition, move the logs from the Helm actions themselves to the
"debug" log level (while still including them in Kubernetes Events in
case of a failure), in favor of the logs produced by the `reconcile`
package itself. While moving the logs from the Helm storage to the
"trace" log level, as they only contain information about e.g. writes
to a Secret.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This in an attempt to maintain compatability with earlier documented
inclusion and exclusion lists for Alerts, like the following:
```
eventSources:
- kind: HelmRelease
name: demo
inclusionList:
- ".*.upgrade.*succeeded.*"
```
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
The primary reason for this is the alphabetical ordering of `kubectl
describe`, which caused the fields to be listed in separate places
instead of a bundle.
From a programmatic perspective, it is also great because it is now much
easier to reset any previous state when e.g. uninstalling a release. As
we can simply write an empty struct to erase any memory of a previous
release, instead of having to deal with multiple fields.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This will allow the controller to pick the right method for digest
calculations when we for example add new data into the calculation.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures certain edge-cases around the availability of the service
account and/or KubeConfig are handled.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This is a better way of dealing with this situation, as the previous
logic would result in an `ErrNoStorageUpdate`.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
"With hope comes the potential for both triumph and tribulation."
Due to difficulties beyond the time I have at hands at present[1], the
separate reconciler which took care of ensuring the HelmChart of the
HelmRelease was kept up-to-date has been transformed into a
sub-reconciler.
The behavior of the sub-reconciler remains largely unchanged, except the
required changes to deal with the lack of possibilities to requeue.
Effectively, this means that instead of e.g. deleting the HelmChart
object, requeue, and create it again. This is now handled in a single
operation, unless the deletion fails.
[1]: The core of the issue is that deregistration of finalizers becomes
difficult due to the behavior of the patch helper, and unavailability of
list merges for patch operations on Custom Resources within Kubernetes.
This means that when two reconcilers simultaneously work on the
deregistration of the finalizers, and one succeeds before the other. The
last finishing reconciler will attempt to add the finalizer of the other
reconciler back, as it did exist at the start of their reconciliation
run.
Attempts to work around this (for example, by using an optimistic lock
on the patch operation of the finalizers field) would cause new issues.
As Kubernetes will then delete the object as soon as the patch has
succeeded, and before the reconciliation process actually ends.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This introduces an `acl` package in `internal` which globally configures
the allowance to namespaced references, instead of having to pass on a
variable everywhere.
For the sake of security, the default behavior of the package itself is
to _not_ allow cross namespace references. However, the behavior of the
controller remains unchanged, and the configuration flag still enables
the allowance by default.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Sadly, Helm more than often ends error messages with `\n\n`. Trim this
space to ensure we produce pretty messages.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
When an object is marked as under deletion, the API server will reject
any attempt to register new finalizers. Given this, handling the
deletion timestamp always has to come before an attempt to register
the finalizer.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This ensures they both have the same observation on the last
modifications made to the object. Preventing possible scenarios where
a condition would not be removed because it wasn't set at the start of
the reconcile run, then added, and then removed. Causing it to go
unnoticed during the diff calculation.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This adds the base wiring to get the controller to work with the
v2beta2 API and the newly introduced packages in `internal/`.
In essence, this means that from now on the controller will utilize all
new code for the reconciliation of the HelmRelease resource.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
- Use `Unknown` status for the `TestSuccess` condition when tests
have not been run yet.
- Update Ready summarization logic to incorportate conditions with an
Unknown status. Within the context of readiness, this always caises
Ready=False when the condition is included in the summarization.
- Variety of tiny fixes.
- Tiny nits in test mocks to prevent confusion.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This includes the "token" in the emitted events which is used to rate
limit events received by the notification-controller.
Either by using the already calculated config (values) digest, or by
calculating it for the current reconciliation request in scenarios
where it isn't available from made observations.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This provides more context to individual log entries (and the duration
between individual log lines) while e.g. printing them in an event.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit adds an atomic release reconciler, capable of stepping
through a series of Helm actions. In addition, it adds the last bits
around eventing and summarizing the end state of the Condition types
into e.g. a Ready condition.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This solves the issue where a release name composed out of e.g.
the target namespace and name of the HelmRelease itself would exceed
the >=53 character length. By calculating the SHA256 checksum of the
release name, taking the first 12 characters of this checksum and
appending it to the release named trimmed to 40 characters separated
by a hyphen (`<long-release-name>-abcdef12345678`).
Signed-off-by: Hidde Beydals <hello@hidde.co>
This gives more fine-grain control over what release must be targeted,
as we do not always want to rely on the current spec but rather on e.g.
a release we have made ourselves with a previous configuration for
garbage collection purposes.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This allows for requesting the count of non-empty values in the ring
buffer, and thus the number of log lines.
Signed-off-by: Hidde Beydals <hello@hidde.co>
- Change the map with Helm release test hooks to a pointer map. This
allows (in combination with the constrains around JSON serialization)
to distinguish a release _without_ a test run from a release _with_
test run but no tests (an empty map).
- Add `GetTestHooks` and `SetTestHooks` methods to help circumvent some
of the common problems around working with a pointer map in Go (e.g.
not being capable of iterating over it using range).
- Add `HasBeenTested` and `HasTestInPhase` methods to help make
observations on captured release information.
- Add `StorageNamespace` to Status to allow for observations of
configuration changes which are mutating compared to the spec.
- Add `GetActiveRemediation` helper method to get the active
remediation strategy based on the presence of Current and/or Previous
release observations in the Status of the object.
- Add `ReleaseTargetChanged` helper method to determine if an immutable
release target changed has occurred, in which case e.g. garbage
collection needs to happen before performing any other action.
- Add `GetCurrent`, `HasCurrent`, `GetPrevious` and `HasPrevious`
helper methods to ease access to their values nested in the Status.
- Add `FullReleaseName` and `VersionedChartName` helper methods to e.g.
allow printing full name references in Condition and Event messages
which can be placed in a point in time based on metadata more
familiar to a user than for example the observed generation.
- Change `GetFailureCount` and `RetriesExhausted` signatures of
`Remediation` interface to take a pointer. This eases use of the API,
as generally speaking a (Kubernetes) API object is a pointer.
- Move methods from `HelmReleaseSpec` to `HelmRelease`, this is easier
to access and matches `GetConditions`, etc.
- Remove `DeploymentAction` interface and `GetDescription` from
`Remediation` interface as this is no longer of value.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This to allow the Flux CLI to e.g. enable the dry-run flag on an action
outside of the HelmRelease spec, and inject other (user input based)
modifications.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This provides a rough (but not flawless) outline for determining the
sub-reconciler which should run based on the state of the `HelmRelease`
API object, and the Helm storage.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds a `reconcile` package with the reconciliation and (status)
observation logic for individual Helm actions, but no glue to loop
through them till desired state.
All actions have individual `ActionReconciler` implementations which
construct their `action.Configuration` out of a factory, so the Helm
client can be shared between sub-reconcilers. They all present a
`ReconcilerType`, allowing an iterator to e.g. stop after running
every type just once.
The observation model can be explained as follows, but may lack some
minor details:
- The observed release has to match the release target of the
HelmRelease object
- ActionReconcilers of type "release" move Current to Previous
when they see a higher release revision. They then write the
new release to Current, and continue to observe writes to
revisions that match either version
- Remediation only updates Current
- Test updates Current and Current.TestHooks
- Unlock updates Current
After running the action, the reconcilers observe both the action
result and the state of the object. This allows them to distinguish
certain types of errors which are otherwise hard to detect.
For example, errors which do not cause drift to the Helm storage, or a
change of release version compared to Current for actions which do not
provide a version target flag.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds a `release` package which allows to create (minified)
`ObservedRelease` copy of a Helm release object. This
`ObservedRelease` contains sufficient data to detect changes
to the storage object made by Helm actions run manually, and a variety
of malicious changes (but not all, at present).
The data in an `ObservedRelease` can be filtered using a `DataFilter`,
this allows for example to filter out test hooks to prevent the
controller from taking action on a manually run `helm test`.
The consumer can combine the `ObservedRelease` with a Helm storage
observer to take snapshots of the release object as written to the
storage by a Helm action. To record this on a `HelmRelease` v2beta2 API
object, the `ObservedRelease` can be transformed into a
`HelmReleaseInfo` API object which can be recorded as either the
Current or Previous release in the status.
During the transformation, the digests of both the `ObservedRelease`
object and release config are calculated using the canonical algorithm.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit introduces an `action` package which allows the consumer to
run Helm actions using the instructions from a `HelmRelease` v2beta2
API object.
The actions do not determine if there is a desire be run, nor do they
record state on the object. This can however be injected by the caller
using the simplified observing Helm storage driver, which now iterates
over a list of callback functions after persisting an object instead
of keeping state.
This separation of concerns would allow e.g. the Flux CLI later on
to run actions (but with a dry-run flag or different storage
configuration) using the object in the same manner as the controller.
Some minor changes have been made to the `postrender` and `runner`
package to allow the code to co-exist while we are inbetween API
versions.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This is an initial introduction, and still subject to changes. The
storage version is still configured to v2beta1. This allows low
level packages to already work with the new object data, but keeps
it away from the reconciler for now.
The changes mainly focus around removing the helper methods from the
API, and to enrich the status object with more data about the current
and previous revision. With the goal to deprecate all `LastAttempted*`
and `LastApplied*` fields, as this data is now available in `Current`
and `Previous`.
Signed-off-by: Hidde Beydals <hello@hidde.co>
Plus change the tests a tiny bit to work with Gomega, and break the
further API free from direct attachment to our Helm API objects.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit moves various generic bits out of the reconciler into
separate modules, while adding more test coverage.
Some of the logic around merging chart values from references has been
improved to work with `client.Object`, instead of two separate maps.
In addition, the option to override the hostname of an Artifact has
been removed. It was undocumented and for testing purposes only, which
these days can be better achieved by e.g. configuring the
`--storage-adv-addr`.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This moves the HelmChart template handling to a separate reconciler,
with predicates detecing relevant changes. The idea is that this would
both facilitate working _without_ chart templates but with references
in the future, and to reduce cognitive load while working with
reconciler logic.
The predicate uses `DeepEqual` from `k8s.io/apimachinery/pkg/api/equality`
to inspect the Chart template objects of the old and new HelmRelease
object in the update event.
The reconciler uses server-side apply to create or update the HelmChart
on the cluster, and emits an event based on the change set of the
action. It does not produce any diff yet, as the server-side apply
library at present does not provide a way to gain access to an "old"
versus "new" objects after performing an apply. The `diff` package
has however been prepared to allow diffing Unstructured objects.
As this reconciler has a separate life-cycle, a new
`chart.finalizers.fluxcd.io` finalizer has been introduced to ensure
a HelmChart is properly garbage collected before the HelmRelease is
allowed to be deleted.
The implementation on the release reconciler's end is a rough sketch,
but in working shape. The foresight is that much of the reconciler will
change when the release logic will be adjusted to work with the earlier
introduced storage observer.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This adds an observer which wraps around a Helm storage driver, to keep
track of the release metadata as written to the storage. This enables
you to work with, and compare release data as persisted by Helm.
Without having to rely on the result as returned by the Helm SDK. Which
at times of an error, may differ from last written state.
The observer does at present expect to be watching a single namespace,
and was designed without working with multiple releases simultianiously
into account, although this should theoretically still work.
The releases are at stored in a simple map by index storage key, which
are unique to the namespace. The `ObservedRelease` objects the keys hold are
overwritten on sequential writes to the same release object, and
returned by getter methods as deep copies.
This could theoretically be changed to observing e.g. all writes, I have
left this as a refinement TODO while actually implementing it in the
reconciler. The same goes for the included metadata, which might be not
all relevant.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This includes an update of `oras.land/oras-go` to `v1.2.4` due to
otherwise incompatible signature changes.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This addresses an issue in which the defunct `DefaultServiceAccount`
from the `HelmReleaseReconciler` was being used to construct the
impersonator used by the differ.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
To prevent spurious newlines between the error message and the captured
logs, as at times Helm ends error with one or multiple newlines.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This addresses a regression in the Helm log capturing introduced in
3b25041385, which prevented valuable
information from the Kube client logs (e.g. the specific reason for a
timeout) to be added to the event emitted in case of a failure.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Use the metrics helper to record all the metrics. Metrics helpers
ensures that the metrics for deleted objects are deleted as well.
Move all the metrics recording to be performed at the very end of the
reconciliation. Realtime metrics for readiness is no longer recorded as
it will be removed in a future version for CRD metrics collected using
kube-state-metrics. Updating the object status with realtime readiness
should provide the readiness to CRD metrics watchers.
`HelmReleaseReconciler.reconcileDelete()` is modified to receive a
pointer HelmRelease object so that any modifications on the object is
reflected on the object instance that's passed to the metrics recorder.
This is not needed for `HelmReleaseReconciler.reconcile()` as it returns
a new copy of the object that's saved in the same object variable,
overwriting the object instance with the updates.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
This adds a `--interval-jitter-percentage` flag to the controller to
add a +/- percentage jitter to the interval defined in a HelmRelease
(defaults to 5%).
Effectively, this results in a reconciliation every 9.5 - 10.5 minutes
for a resource with an interval of 10 minutes.
Main reason to add this change is to mitigate spikes in memory and
CPU usage caused by many resources being configured with the same
interval.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
- github.com/fluxcd/pkg/apis/event to v0.5.2
- github.com/fluxcd/pkg/apis/meta to v1.1.2
- github.com/fluxcd/pkg/runtime to v0.41.0
- github.com/fluxcd/pkg/ssa to v0.30.0
- github.com/fluxcd/source-controller/api to v1.0.1
- github.com/onsi/gomega to v1.27.10
- github.com/opencontainers/go-digest/blake3 to v0.0.0-20230801144141-122dc6384261
- helm.sh/helm/v3 to v3.12.2
- k8s.io/api to v0.27.4
- k8s.io/apiextensions-apiserver to v0.27.4
- k8s.io/apimachinery to v0.27.4
- k8s.io/cli-runtime to v0.27.4
- k8s.io/client-go to v0.27.4
- sigs.k8s.io/cli-utils to v0.35.0
- sigs.k8s.io/controller-runtime to v0.15.1
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
- github.com/fluxcd/pkg/apis/meta to v1.1.2
- k8s.io/apiextensions-apiserver to v0.27.4
- k8s.io/apimachinery to v0.27.4
- sigs.k8s.io/controller-runtime to v0.15.1
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
In some controller we already support multiple API versions at the
same time. In order to streamline the docs structure, the necessary
changes to do the same in this repo are applied here as well.
refs fluxcd/website#1577
Signed-off-by: Max Jonas Werner <mail@makk.es>
This allows GitHub Action workflows to be triggered for the PR created
by the bot.
As things are now triggered by the bot, elevated permissions of the
workflow itself are no longer required.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This adds a GitHub Action workflow to sync the labels from a YAML file
in `.github/labels.yaml`, in combination with fetching the standard
labels from `fluxcd/community`.
In terms of colors, I am still trying to figure out what looks best.
But this should be a good start to at least kick things off.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
This workflow automatically backports pull requests labeled with
`backport:<release series branch>`.
For example, `backport:release/v1.0.x` to backport the pull request
to a `release/v1.0.x` branch.
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
Generate SLSA level 3 provenance attestations for the controller release assets and for the multi-arch container images.
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
Likely after the upgrade to controller-runtime v0.15.0 a regression
surfaced for long-running reconciliations of HelmRelease resources (e.g.
for charts having pre-upgrade hooks taking a few minutes to complete).
This regression would cause the controller to immediately re-run the
upgrade after a successful upgrade, thus entering an almost-endless
loop.
Apparently, the only fix to this issue is to ensure
`.Status.LastReleaseRevision` is updated as soon as possible in the
reconiliation cycle rather than wait for the update at the end of the
cycle.
Signed-off-by: Aurel Canciu <aurelcanciu@gmail.com>
This prerelease promotes the `HelmRelease` API from `v2beta1` to `v2beta2`.
The promotion of the API is accompanied by a number of new features and bug
fixes. Refer to the highlights section below for more information.
In addition to the API promotion, this prerelease updates the controller
dependencies to their latest versions. Making the controller compatible with
Kubernetes v1.28.x, while updating the Helm library to v3.13.2, and the builtin
version of Kustomize used for post-rendering to v5.3.0.
Lastly, the base controller image has been updated to Alpine v3.19.
### Highlights
#### API changes
The upgrade is backwards compatible, and the controller will continue to
reconcile `HelmRelease` resources of the `v2beta1` API without requiring any
changes. However, making use of the new features requires upgrading the API
version.
- Drift detection and correction is now enabled on a per-release basis using
the `.spec.driftDetection.mode` field. Refer to the [drift detection section](https://github.com/fluxcd/helm-controller/blob/v0.37.0/docs/spec/v2beta2/helmreleases.md#drift-detection)
in the `v2beta2` specification for more information.
- Ignoring specific fields during drift detection and correction is now
supported using the `.spec.driftDetection.ignore` field. Refer to the
- Helm tests can now be selectively run using the `.spec.test.filters` field.
Refer to the [test filters section](https://github.com/fluxcd/helm-controller/blob/v0.37.0/docs/spec/v2beta2/helmreleases.md#filtering-tests)
in the `v2beta2` specification for more details.
- The controller now offers proper integration with [`kstatus`](https://github.com/kubernetes-sigs/cli-utils/blob/master/pkg/kstatus/README.md)
and sets `Reconciling` and `Stalled` conditions. See the [Conditions section](https://github.com/fluxcd/helm-controller/blob/v0.37.0/docs/spec/v2beta2/helmreleases.md#conditions)
in the `v2beta2` specification to read more about the conditions.
- The `.spec.maxHistory` default value has been lowered from `10` to `5` to
increase the controller's performance.
- A history of metadata from Helm releases up to the previous successful release
is now available in the `.status.history` field. This includes any Helm test
results when enabled.
- The `.patchesStrategicMerge` and `.patchesJson6902` Kustomize post-rendering
fields have been deprecated in favor of `.patches`.
- A `status.lastAttemptedConfigDigest` field has been introduced to track the
last attempted configuration digest using a hash of the composed values.
- A `.status.lastAttemptedReleaseAction` field has been introduced to accurately
determine the active remediation strategy.
- The `.status.lastHandledForceAt` and `.status.lastHandledResetAt` fields have
been introduced to track the last time a force upgrade or reset was handled.
This to accomadate newly introduced annotations to force upgrades and resets.
- The `.status.lastAppliedRevision` and `.status.lastReleaseRevision` fields
have been deprecated in favor of `.status.history`.
- The `.status.lastAttemptedValuesChecksum` has been deprecated in favor of
`.status.lastAttemptedConfigDigest`.
Although the `v2beta1` API is still supported, it is recommended to upgrade to
the `v2beta2` API as soon as possible. The `v2beta1` API will be removed after
6 months.
To upgrade to the `v2beta2` API, update the `apiVersion` field of your
`HelmRelease` resources to `helm.toolkit.fluxcd.io/v2beta2` after updating the
controller and Custom Resource Definitions.
#### Other notable improvements
- The reconciliation model of the controller has been improved to be able to
better determine the state a Helm release is in. An example of this is that
enabling Helm tests will not require a Helm upgrade to be run, but instead
will run immediately if the release is in a `deployed` state already.
- The controller will detect Helm releases in a `pending-install`, `pending-upgrade`
or `pending-rollback` state, and wil forcefully unlock the release (to a
`failed` state) to allow the controller to reattempt the release.
- When drift correction is enabled, the controller will now attempt to correct
drift it detects by creating and patching Kubernetes resources instead of
running a Helm upgrade.
- The controller emits more detailed Kubernetes Events after running a Helm
action. In addition, the controller will now emit a Kubernetes Event when
a Helm release is uninstalled.
- The controller provides richer Condition messages before and after running a
Helm action.
- Changes to a HelmRelease `.spec` which require a Helm uninstall for the
changes to be successfully applied are now detected. For example, a change in
`.spec.targetNamespace` or `.spec.releaseName`.
- When the release name exceeds the maximum length of 53 characters, the
controller will now truncate the release name to 40 characters and append a
short SHA256 hash of the release name prefixed with a `-` to ensure the
release name is unique.
- New annotations have been introduced to force a Helm upgrade or to reset the
number of retries for a release. Refer to the [forcing a release](https://github.com/fluxcd/helm-controller/blob/v0.37.0/docs/spec/v2beta2/helmreleases.md#forcing-a-release)
and [resetting remediation retries](https://github.com/fluxcd/helm-controller/blob/v0.37.0/docs/spec/v2beta2/helmreleases.md#resetting-remediation-retries)
sections in the `v2beta2` specification for more information.
- The digest algorithm used to calculate the digest of the composed values and
hash of the release object can now be configured using the `--snapshot-digest-algo`
controller flag. The default value is `sha256`.
- When the `HelmChart` resource for a `HelmRelease` is not `Ready`, the
Conditions of the `HelmRelease` will now contain more detailed information
about the reason.
To get a full overview of all changes, and see examples of the new features.
Please refer to the [v2beta2 specification](https://github.com/fluxcd/helm-controller/blob/v0.37.0/docs/spec/v2beta2/helmreleases.md).
Matheus Pimenta
cappyzawa
Stefan Prodan
Yves Mettier
dependabot[bot]
Martin Hoffmann
abhijith-darshan
leigh capili
drawdrop
Stevo Slavic
Kumar Mallikarjuna
Hidde Beydals
Luis Davim
Bogdan-Adrian Burciu
Sunny
Sunny
Chris Werner Rau
Florian Ströger
Florian Forster
souleb
Max Jonas Werner
Max Jonas Werner
Stéphane Este-Gracias
Robin Breathe
Georg Molau
Hidde Beydals
Hidde Beydals
Jiri Tyr
Jiri Tyr
Yiannis Triantafyllopoulos
Somtochi Onyekwere
Max Jonas Werner
Carlos Sanchez
Aurel Canciu
Martin Hoffmann