v0.3.115

Compare Source

v0.3.114

Compare Source

v0.3.113

Compare Source

v0.3.112

Compare Source

v0.3.111

Compare Source

v0.3.110

Compare Source

v0.3.109

Compare Source

v0.3.108

Compare Source

v0.3.107

Compare Source

Enhancements

Status handling

So far, the observed generation of dependent objects was expected at status.observedGeneration. Some newer projects seem to populate status.conditions[type=*].observedGeneration, additionally, or even exclusively.

Starting with this release, if a status hint of has-observed-generation is present, but no status.observedGeneration is found, the framework will look at .status.conditions[type=Ready].observedGeneration as a fallback.

Secret handling

It is well known that the stringData field of secrets is not handled properly during server-side-apply:

Note:
The stringData field for a Secret does not work well with server-side apply.

To overcome, we will now merge stringData into data before applying and clear stringData. This should be consistent with the logic that would otherwise happen in the API server:

All key-value pairs in the stringData field are internally merged into the data field. If a key appears in both the data and the stringData field, the value specified in the stringData field takes precedence.

See SAP#313.

Deletion handling

It is difficult to move dependent objects from one component to another. That means: adding it to the source manifest of the new one, and removing it from the sources of the old one.

The typical flow looks like this:

• ensure that the receiving component (the new owner) is reconciled before the sending component (the previous owner)
• annotate the dependent object (in the manifest source used by the new component) with adoption-policy: always, at least for a certain time, until the change is rolled out everywhere.

Then, when applying that, the new component will force-adopt the existing object, and the old component will run into an owner conflict error. This either has then to be solved manually by patching the old component's inventory, or (in a previous apply), the object must have been applied by the old component with delete-policy: orphan or delete-policy: orphan-on-apply.

It would be nice (and reasonable) if - upon dependent deletion, either due to component apply or component deletion - dependents with no or a different owner would be auto-orphaned. This would eliminate the need of the manual post-processing or the preflight apply run setting delete policies (as explained above).

v0.3.106

Compare Source

v0.3.105

Compare Source

v0.3.104

Compare Source

v0.3.103: v03.103

Compare Source

Bug fixes

Fixes #​305.

v0.3.102

Compare Source

Bug fixes

This release fixes #​302.

v0.3.101: v03.101

Compare Source

Bug fixes

Fixes SAP#299.

v0.3.100

Compare Source

v0.3.99

Compare Source

Enhancements

KustomizeGenerator

We add the possibility to make the KustomizeGenerator ignore certain files by creating a file called .component-ignore in the kustomization directory (that is the directory passed to NewKustomizeGenerator().
The file uses the usual .gitignore syntax.

Notes:

• Other than git we honour this file only in the root of the specified kustomization, but not in any subdirectories.
• The files .component-config.yaml and .component-ignore are always included.
• Files excluded will not be rendered, and will not be included into a generated kustomization.yaml (in case the directory does not have one).
• However, excluded files can still be retrieved by the readFile function (and related functions).

v0.3.98

Compare Source

Enhancements

This release adds the following metrics:

// # HELP component_operator_runtime_component_state Current state of a component
// # TYPE component_operator_runtime_component_state gauge
ComponentState = prometheus.NewGaugeVec(
	prometheus.GaugeOpts{
		Name: prefix + "_component_state",
		Help: "Current state of a component",
	},
	[]string{"controller", "group", "kind", "namespace", "name", "state"},
)

// # HELP component_operator_runtime_dependents_total Number of dependent objects
// # TYPE component_operator_runtime_dependents_total gauge
Dependents = prometheus.NewGaugeVec(
	prometheus.GaugeOpts{
		Name: prefix + "_dependents_total",
		Help: "Number of dependent objects",
	},
	[]string{"controller", "group", "kind", "namespace", "name"},
)
// # HELP component_operator_runtime_unready_dependents_total Number of unready dependent objects
// # TYPE component_operator_runtime_unready_dependents_total gauge
UnreadyDependents = prometheus.NewGaugeVec(
	prometheus.GaugeOpts{
		Name: prefix + "_unready_dependents_total",
		Help: "Number of unready dependent objects",
	},
	[]string{"controller", "group", "kind", "namespace", "name"},
)

v0.3.97

Compare Source

v0.3.96

Compare Source

Enhancements

This release makes the force-reapply interval configurable on component and object level.
So far, every object was force-reapplied to the cluster every 60 minutes (even it is seemed to be in sync according to digests). Now, that interval can be tweaked

• on component level by implementing the new interface

  type ReapplyConfiguration interface {
    // Get force-reapply interval. Should be greater than the effective requeue interval. If a value smaller than the
    // effective requeue interval is specified, the force-reapply might be delayed until the requeue happens.
    // A return value of zero means to use the framework default.
    GetReapplyInterval() time.Duration
  }

  or by including the convenience type ReapplySpec into the component's spec.

• on object level (which has higher precedence than the value specified on component level) by setting the annotation
  mycomponent-operator.mydomain.io/reapply-interval.

v0.3.95

Compare Source

Fixes/Improvements

This release makes the backoff (used by the reconciler in non-error situations) a little less aggressive.
So far, about 50 almost immediate retries were possible in the first 5 seconds. Now that is reduced to 5 retries, and also the medium backoff range (happening before the final maxDelay backoff kicks in) is relaxed a bit.

To be precise: per backoff topic, the backoff is now

• 5 quick roundtrips (exponential, below 1s)
• then 15 roundtrips at 1s
• then 30 roundtrips at 2s
• then rounttrips at 10s.

v0.3.94

Compare Source

v0.3.93

Compare Source

v0.3.92

Compare Source

Fixes

This release is a bugfix release. It fixes #​279 and #​281.

v0.3.91

Compare Source

Enhancements

This release enhances HelmGenerator and KustomizeGenerator, adding mechanisms to access files from the provided Helm chart resp. Kustomization directory.

For HelmGenerator that means, that the .Files builtin is now supported. With some small differences to the original Helm behavior:

• all paths reserved by Helm (such as Chart.yaml, templates/, crds/ and so on) cannot be retrieved through .Files
• since HelmGenerator currently does not honor the .helmignore file at all, files that would be excluded with regular Helm can be accessed through .Files with HelmGenerator.

For KustomizeGenerator, there are now three new template functions available:

• readFile: takes a path relative to the Kustomization directory and returns the raw content (as []byte slice)
• existsFile: also expects a path relative to the Kustomization directory and returns a boolean indicating whether the file exists or not
• listFiles: accepts a pattern and returns a all matching file paths in the Kustomization directory as string list.

v0.3.90

Compare Source

v0.3.89

Compare Source

v0.3.88

Compare Source

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

Compare Source

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.

v0.3.86: v03.86

Compare Source

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

Compare Source

v0.3.84

Compare Source

Changes

This is a bugfix release; see SAP#260.

v0.3.83

Compare Source

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

Compare Source

v0.3.81

Compare Source

v0.3.80

Compare Source

v0.3.79

Compare Source

Enhancements

So far, the framework emitted really many component events, mostly if the component is in Processing state. That often exceeded the burst of the event broadcaster provided by controller-runtime (b=25, r=1/300, see https://github.com/kubernetes/client-go/blob/b46275ad754db4dd7695a48cd3ca673e0154dd9e/tools/record/events_cache.go#L43).

We change that now. If there are identical subsequent events produced for a component, only the first one will be emitted within 5 minutes; after 5 minutes, again one instance of the throttled event may be sent, and so on.

v0.3.78

Compare Source

Notable changes

• It is now written in stone: hooks must not change the component's metadata or spec; this was actually always clear, but now it is really explicitly forbidden.
• The component digest (which is for example passed to generators and influencing the status.ProcessingDigest) is now considering the metadata.generation of the component.

v0.3.77

Compare Source

Enhancements

• New methods are added to cluster.Client:

  type Client interface {
      // ...
      // Return a rest config for this client.
      Config() *rest.Config
      // Return a http client for this client.
      HttpClient() *http.Client
  }

• In addition there is a new reconciler option

  type ReconcilerOptions struct {
      // ...
      // NewClient allows to modify or replace the default client used by the reconciler.
      // The returned client is used by the reconciler to manage the component instances, and passed to hooks.
      // Its scheme therefore must recognize the component type.
      NewClient NewClientFunc
  }

  with

  type NewClientFunc func(clnt cluster.Client) (cluster.Client, error)

  This allow to replace or modify the default component/hook client that would be used by the reconciler

  • to manage component instances
  • when calling hooks.

v0.3.76

Compare Source

v0.3.75

Compare Source

Enhancements

Additional managed types

By its nature, component-operator-runtime tries to handle extension types (such as CRDs or API groups added through APIService federation), and instances of these types, in a smart way.

That is, if the component contains extension types, and also instances of these types, it tries to process things in the right order; that means, during apply the instances will be applied as late as possible (to ensure that controllers and webhooks are up); and during delete, the instances will be deleted as early as possible (to ensure that controllers and webhooks are still there). Furthermore, during deletion, foreign instances (that is, instances of these types that are not part of the component) block the deletion of the whole component.

Sometimes, components are implicitly adding extension types to the cluster; in the sense that the extension types are not explicitly part of the manifests, but added in the dark through controllers, once running. A typical example are crossplane providers.

This PR tries to add some relief in this situation. Components can now list 'additional managed types', by implementing the TypeConfiguration interface; these 'additional managed types' will be treated in the same way as extension types which are explicitly mentioned in the manifest.

Improved APIService handling

Up to now, APIService objects were deployed along with the other regular (that was: unmanaged) objects of the current apply wave. As a consequence, if the federated API server was not yet ready, stale group version errors were returned by the discovery API of the main API server. To overcome this problem, APIService objects receive a special handling now, in the sense that they are reconciled (in the apply wave) after all other regular objects, and before all managed instances. That means: within each apply order, objects are deployed to readiness in three sub stages

• regular objects (all 'normal' objects)
• late objects (currently, this is only APIService objects)
• instances of managed types (that is instances of types which are added in this component as CRD or through an APIService)

Within each of these sub groups, the static ordering defined in sortObjectsForApply() is effective.

More robust handling of external recreations happening during deletion

Previously there was a rare race condition while deleting objects (either during component delete or component apply):

The old logic was:

1. Delete objects that are are to be deleted (if they are in phase ScheduledForDeletion during apply or if the whole component is being deleted); if successful (that is API server responds with 2xx) then the inventory status of the dependent object is set to Deleting.
2. Wait until object is gone.

Now, if the object was recreated by someone right between 1. and 2. then the reconciler went stuck.
Note that really does not happen usually (also because the critical period is very, very short).

To overcome, we are now checking the deletion timestamp of the dependent object (if still or again existing). If it has none, then we check the owner; if it is not us, then we give the object up (because apparently, someone else has just recreated it).

v0.3.74

Compare Source

Improvements

So far, there was no special logic to check status status of CustomResourceDefinition and APIService resources.
That is, they were considered ready immediately, which was causing problems (for example, lookup errors when querying the discovery API immediately after creating an APIService, such as ... stale GroupVersion discovery ...).

To mitigate, the default status analyzer now evaluates existing conditions (such as the Available condition of APIService).

v0.3.73

Compare Source

v0.3.72

Compare Source

Incompatible changes

Background: values passed to the built-in generators and transformers
are of type map[string]any. Of course, templates are rendered with the missingkey=zero option.
But still, if a key is missing in the values, the empty value of any (returned in this case)
makes the go templating engine return <no value> in that case.

Helm decided to override that by replacing all occurrences of the string <no value> in any template output.
Starting with this PR we adopt the helm approach, and do the same.

v0.3.71

Compare Source

Incompatible changes

• The semantics of deletion policy Orphan is slightly changed; previously Orphan had no effect if a dependent object became redundant during apply (that is, it was part of the component manifest before, and is no longer now). Now, if an object has an effective deletion policy Orphan, then it will be always orphaned if
  • the object becomes redundant during apply or
  • the component itself is deleted.

Enhancements

• To allow more fine-granular control over the orphan behaviour, there are two new deletion policy values: OrphanOnApply and OrphanOnDelete, with the obvious meaning.
• A new parameterless template function apiResources is added for KustomizeGenerator. It returns []*metav1.APIResourceList, as returned by the discovery client's method ServerGroupsAndResources, see https://pkg.go.dev/k8s.io/[email protected]/discovery#ServerResourcesInterface.ServerGroupsAndResources.

v0.3.70

Compare Source

Changes

This release finalizes the reworking of the force-reapply logic started in https://github.com/SAP/component-operator-runtime/releases/tag/v0.3.62.

So far, a dependent object was applied to the cluster if

• it does not exist or
• it exists and is out of sync (that is the annotated digest does not match) or
• it exists and its status.inventory[].lastAppliedAt timestamp is set and is more than 60m in the past.

The third condition is now changed to

• it exists and its status.inventory[].lastAppliedAt timestamp is not set, or is set and is more than 60m in the past.

As a consequence, the component CRD now must contain the status.inventory[].lastAppliedAt field, that is the consumers must have regenerated their CRD to reflect the current component-operator-runtime API types, as already stated in the release notes of v0.3.62.

v0.3.69

Compare Source

Enhancements

Starting with this release, the deletion of dependent objects will fail unless the existing value of the owner-id label of the dependent object matches the component that wants to delete it. If the owner-id label is missing, or the value does not match, the deletion will be rejected.

v0.3.68

Compare Source