v0.3.89

fix(go.mod/go.sum): update module sigs.k8s.io/structured-merge-diff/v…

v0.3.88

Fixes

With restricted privileges (that is not having full cluster-admin rights) Kubernetes checks that (cluster)roles assigned through a (cluster)rolebinding do exist (probably it needs to read it in order to perform the escalation check).
That is, (cluster)roles must be always created before any (cluster)rolebindings referencing them.

Previously, component-operator-runtime applied roles and bindings in one and the same wave; with the effect that a deadlock could happen if the binding happened to be first. This is now corrected, that is, (cluster)roles are created before (cluster)rolebinindings.

v0.3.87

Incompatible changes

This release slightly changes the processing timeout logic.

Previously the processing timeout was reset (means: status.processingSince was set to the current time), and then started counting down whenever the component digest changed. This had the effect that a component starting in Pending state (for example because it is waiting for another dependent component to become ready) might time out before it ever got a chance to really process. With the consequence that, once it eventually started processing, its state was immediately Error with Timeout reason.

From now on, status.processingSince is not set immediately when the digest changes, but later, when the first apply iteration happens after the digest change.

v03.86

Fixes

This is a bugfix release; it fixes #265 and #267.

The logic around the SsaOverride update policy should now work reliably.

Incompatible changes

Previously, with SsaOverride fields owned by field managers starting with kubectl or helm were reclaimed by component-operator-runtime and, if the intended manifest did not have an opinion on these fields, dropped. With that release helm is removed from this list of specially treated field managers. This change is necessary to avoid clashes with flux's helm-controller which uses field manager helm-controller.

v0.3.85

update comments

v0.3.84

Changes

This is a bugfix release; see #260.

v0.3.83

This release is about revisiting/improving the timeout handling of components.

Improving the logic of the processing/timeout flow

It is well-known that every component has a processing timeout. Components can specify the timeout value by implementing the component.TimeoutConfiguration interface. Otherwise (or if a zero timeout is specified), it will be defaulted by the effective requeue interval, which defaults to 10 minutes.

Then, note that a component can be in a 'processing' or 'non-processing' state (which is not directly related to status.state being Processing). Here, 'processing' means that status.processingSince is non-initial. Now, if a component is reconciled, a certain component digest is calculated from the component's annotations, spec and references in the spec (see below for more details about references). Whenever this component digest differs from the current status.processingDigest, then status.processingSince is set to the current time, and status.processingDigest is set to the new component digest.
Roughly spoken, that means a new timeout countdown is started.

In addition to 'processing' a component can be in a 'timeout' state; this is the case if the status.processingSince timestamp lies more than the specified timeout duration in the past. If a component gets into the 'timeout' state

• in non-error situations, then the component status (that is status.state) will be set to Error with condition reason Timeout
• in error situations, then the component status, then the component status will be according to the error (that is, Error or Pending), and the condition reason is set to Timeout.

That means, a timeout can always be reliably detected by checking if the condition reason equals Timeout.

A 'processing' component will be set to 'non-processing' (that is, status.processingSince is cleared) if the component becomes ready (in that case, in addition, one immediate requeue is triggered).

Calculation of the component digest

At the beginning of the reconcilation of a component, a (component) digest is calculated that considers

• the metadata.annotations of the component
• the metadata.generation resp. the spec of the component
• the loaded content of all spec fields having one of the following types:ConfigMapReference, ConfigMapKeyReference, SecretReference, SecretKeyReference, Reference.

Such references will be automatically loaded at the beginning of the reconcile iteration; for the builtinConfigMap and Secret reference types the logic is part of the framework, and for types implementing the

type Reference[T Component] interface {
	Load(ctx context.Context, clnt client.Client, component T) error
	Digest() string
}

interface, the loading and digest logic is to be provided by the implementation. Besides being used in the timeout handling as status.processingDigest, the component digest

• is used when calculating event annotations
• is passed to generators in their context
• is used when calculating the object digest of dependent objects with an effective reconcile policy of OnObjectOrComponentChange.

Roughly speaking, the component digest should identify result of reconciling the component as exact as possible; that means: applying two components with identical digest should produce the same cluster state.

Incompatible changes

Besides the changes outlined above (which should not have a bad impact) this release contains the following incompatible changes:

• so far, if a retriable error occurred, then status.state was set to Pending with reason Pending, respectively to DeletionPending with reason DeletionPending; the reason values are changed to Retrying and DeletionRetrying, respectively
• a new reason Restarting was added, that will be used with status.state being Pending, if the processing state of a component is reset due to a component digest change.

v0.3.82: fix(deps): update non-minor dependencies (#257)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

v0.3.81: fix(deps): update node.js to v23.10.0 (#253)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

v0.3.80: chore(deps): update dependency autoprefixer to v10.4.21 (#249)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>