fix(deps): update non-minor dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence	Type	Update
github.com/sap/component-operator-runtime	v0.3.67 -> v0.3.77					require	patch
k8s.io/apiextensions-apiserver	v0.32.1 -> v0.32.2					require	patch
k8s.io/apimachinery	v0.32.1 -> v0.32.2					require	patch
k8s.io/client-go	v0.32.1 -> v0.32.2					require	patch
k8s.io/code-generator	v0.32.1 -> v0.32.2					require	patch
k8s.io/kube-aggregator	v0.32.1 -> v0.32.2					require	patch
sigs.k8s.io/controller-runtime	v0.20.1 -> v0.20.2					require	patch
sigs.k8s.io/controller-runtime/tools/setup-envtest	1a91ccc -> ab38193					require	digest

---

Release Notes

sap/component-operator-runtime (github.com/sap/component-operator-runtime)

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

kubernetes/apiextensions-apiserver (k8s.io/apiextensions-apiserver)

v0.32.2

Compare Source

kubernetes/apimachinery (k8s.io/apimachinery)

v0.32.2

Compare Source

kubernetes/client-go (k8s.io/client-go)

v0.32.2

Compare Source

kubernetes/code-generator (k8s.io/code-generator)

v0.32.2

Compare Source

kubernetes/kube-aggregator (k8s.io/kube-aggregator)

v0.32.2

Compare Source

kubernetes-sigs/controller-runtime (sigs.k8s.io/controller-runtime)

v0.20.2

Compare Source

What's Changed

• ✨ Expose all Go runtime metrics by @​k8s-infra-cherrypick-robot in https://github.com/kubernetes-sigs/controller-runtime/pull/3100
• 🐛Fix behavior of rate limit option in priorityqueue.AddWithOpts by @​k8s-infra-cherrypick-robot in https://github.com/kubernetes-sigs/controller-runtime/pull/3106
• 🌱 Update dependencies, k8s 1.32.1 by @​k8s-infra-cherrypick-robot in https://github.com/kubernetes-sigs/controller-runtime/pull/3108

Full Changelog: kubernetes-sigs/controller-runtime@v0.20.1...v0.20.2

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 14 additional dependencies were updated
• The go directive was updated for compatibility reasons

Details:

Package	Change
go	1.23.5 -> 1.24.0
github.com/evanphx/json-patch/v5	v5.9.0 -> v5.9.11
github.com/klauspost/compress	v1.17.9 -> v1.17.11
github.com/prometheus/client_golang	v1.20.5 -> v1.21.0
github.com/prometheus/common	v0.55.0 -> v0.62.0
github.com/sap/go-generics	v0.2.25 -> v0.2.28
github.com/spf13/afero	v1.6.0 -> v1.12.0
github.com/spf13/cobra	v1.8.1 -> v1.9.1
github.com/spf13/pflag	v1.0.5 -> v1.0.6
golang.org/x/crypto	v0.31.0 -> v0.32.0
golang.org/x/oauth2	v0.23.0 -> v0.25.0
golang.org/x/sys	v0.28.0 -> v0.29.0
golang.org/x/term	v0.27.0 -> v0.28.0
golang.org/x/time	v0.9.0 -> v0.10.0
k8s.io/api	v0.32.1 -> v0.32.2