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>
Hidde Beydals
Hidde Beydals
Stefan Prodan
dependabot[bot]