v0.3.73: fix(deps): update module github.com/spf13/cobra to v1.9.1 (#232)

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

v0.3.72

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

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/client-go@v0.32.1/discovery#ServerResourcesInterface.ServerGroupsAndResources.

v0.3.70

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

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: fix(deps): update node.js to v23.7.0 (#215)

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

v0.3.67

(Potentially) incompatible changes

• The type reconciler.ReconcilerOptions is changed:

  • The boolean attribute CreateMissingNamespaces is replaced with a new attribute MissingNamespacesPolicy that can have the values Create (default) or DoNotCreate. The default behavior is backwards compatible; only people who explicitly have set the old attribute have to adopt the new notation in the obvious way.
  • Finalizer and field owner used by the reconciler can now explicitly be configured by setting the attributes Finalizer and FieldOwner in the reconciler options. If unset it defaults to the reconciler name passed to reconciler.NewReconciler(), which makes that change backwards compatible.

• The interface component.PolicyConfiguration was enhanced by an additional method GetMissingNamespacesPolicy() reconciler.MissingNamespacesPolicy. People who implemented that interface explicitly have to add this method to their implementation. Most people however probably just include component.PolicySpec into their component's spec type. They don't have to react, but should regenerate their CRD manifest, in order to expose the new field spec.missingNamespacesPolicy which is now contained in component.PolicySpec.

• The type component.ReconcilerOptions is changed in a way similar to reconciler.ReconcilerOptions (that is, the attribute CreateMissingNamespaces is replaced by MissingNamespacesPolicy and new attributes Finalizer and FieldOwner are added). In addition, there is a new option DefaultServiceAccount which allows the name of a service account that can be used during the reconciliation of a component to impersonate the client used to reconcile the dependent objects, as long as the component does not explicitly specify an impersonation or kubeconfig (by implementing the ImpersonationConfiguration or ClientConfiguration interfaces); note that the specified DefaultServiceAccount always refers to the metadata.namespace or the component.

• When a component resource is reconciled, two Kubernetes API clients are constructed:

  • The local client; it always points to the cluster where the component resides. If the component implements impersonation (that is, the component type or its spec implements the ImpersonationConfiguration interface), and an impersonation user or groups are specified by the component resource, then the specified user and groups are used to impersonate the controller's kubeconfig. Otherwise, if a DefaultServiceAccount is defined in the reconciler's options, then that service account (relative to the components metadata.namespace ) is used to impersonate the controller's kubeconfig. Otherwise, the controller's kubeconfig itself is used to build the local client. The local client is passed to generators via their context. For example, the HelmGenerator and KustomizeGenerator provided by component-operator-runtime use the local client to realize the localLookup and mustLocalLookup template functions.
  • The target client; if the component specifies a kubeconfig (by implementing the ClientConfiguration interface), then that kubeconfig is used to build the target client. Otherwise, a local client is used (possibly impersonated), created according the the logic described above. The target client is used to manage dependent objects, and is passed to generators via their context. For example, the HelmGenerator and KustomizeGenerator provided by component-operator-runtime use the target client to realize the lookup and mustLookup template functions.

  This changes the previous impersonation logic a little bit. Other than before, no impersonation happens at all if a kubeconfig is specified (through ClientConfiguration). In addition, relative service accounts returned by GetImpersonationUser() (that is: a user of the form system:serviceaccounts::name, setting an empty namespace), now will be interpreted always relative to the metadata.namespace of the component resource; previously, the namespace specified by a PlacementConfiguration implementation was considered as well; this is no longer the case.

• The clnt parameter of the HelmGenerator and KustomizeGenerator constructors is now ignored (and will be removed in a future release). Instead, these generators always use the local client, constructed as described above.

v0.3.66

fix(deps): update module sigs.k8s.io/controller-runtime to v0.20.1 (#…

v0.3.65: add template functions (must)lookupWithKubeConfig (#181)

* add template functions (must)lookupWithKubeConfig

* change kubeconfig type from []byte to string

v0.3.64

update CONTRIBUTING