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>
Hidde Beydals