Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(deps): update non-minor dependencies #131

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Feb 6, 2025

This PR contains the following updates:

Package Type Update Change Age Adoption Passing Confidence
docker.io/bitnami/kubectl (source) patch 1.32.1-debian-12-r5 -> 1.32.2-debian-12-r3 age adoption passing confidence
docker.io/bitnami/os-shell (source) patch 12-debian-12-r36 -> 12-debian-12-r39 age adoption passing confidence
github.com/cert-manager/cert-manager require patch v1.17.0 -> v1.17.1 age adoption passing confidence
github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring require patch v0.80.0 -> v0.80.1 age adoption passing confidence
github.com/redis/go-redis/v9 require patch v9.7.0 -> v9.7.1 age adoption passing confidence
github.com/sap/admission-webhook-runtime require patch v0.1.57 -> v0.1.59 age adoption passing confidence
github.com/sap/component-operator-runtime require patch v0.3.69 -> v0.3.75 age adoption passing confidence
github.com/sap/go-generics require patch v0.2.26 -> v0.2.28 age adoption passing confidence
k8s.io/api require patch v0.32.1 -> v0.32.2 age adoption passing confidence
k8s.io/apiextensions-apiserver require patch v0.32.1 -> v0.32.2 age adoption passing confidence
k8s.io/apimachinery require patch v0.32.1 -> v0.32.2 age adoption passing confidence
k8s.io/client-go require patch v0.32.1 -> v0.32.2 age adoption passing confidence
k8s.io/code-generator require patch v0.32.1 -> v0.32.2 age adoption passing confidence
k8s.io/kube-aggregator require patch v0.32.1 -> v0.32.2 age adoption passing confidence
sigs.k8s.io/controller-runtime require patch v0.20.1 -> v0.20.2 age adoption passing confidence
sigs.k8s.io/controller-runtime/tools/setup-envtest require digest 2e8ba92 -> 9024933 age adoption passing confidence
sigs.k8s.io/controller-tools require patch v0.17.1 -> v0.17.2 age adoption passing confidence

Release Notes

cert-manager/cert-manager (github.com/cert-manager/cert-manager)

v1.17.1

Compare Source

prometheus-operator/prometheus-operator (github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring)

v0.80.1: 0.80.1 / 2025-02-19

Compare Source

  • [BUGFIX] Fix msteamsv2_configs to work with either webhook_url or webhook_url_file. #​7352
redis/go-redis (github.com/redis/go-redis/v9)

v9.7.1

Compare Source

Changes

  • Recognize byte slice for key argument in cluster client hash slot computation (#​3049)
  • fix(search&aggregate):fix error overwrite and typo #​3220 (#​3224)
  • fix: linter configuration (#​3279)
  • fix(search): if ft.aggregate use limit when limitoffset is zero (#​3275)
  • Reinstate read-only lock on hooks access in dialHook to fix data race (#​3225)
  • fix: flaky ClientKillByFilter test (#​3268)
  • chore: fix some comments (#​3226)
  • fix(aggregate, search): ft.aggregate bugfixes (#​3263)
  • fix: add unstableresp3 to cluster client (#​3266)
  • Fix race condition in clusterNodes.Addrs() (#​3219)
  • SortByWithCount FTSearchOptions fix (#​3201)
  • Eliminate redundant dial mutex causing unbounded connection queue contention (#​3088)
  • Add guidance on unstable RESP3 support for RediSearch commands to README (#​3177)

🚀 New Features

  • Add guidance on unstable RESP3 support for RediSearch commands to README (#​3177)

🐛 Bug Fixes

  • fix(search): if ft.aggregate use limit when limitoffset is zero (#​3275)
  • fix: add unstableresp3 to cluster client (#​3266)
  • fix(aggregate, search): ft.aggregate bugfixes (#​3263)
  • SortByWithCount FTSearchOptions fix (#​3201)
  • Recognize byte slice for key argument in cluster client hash slot computation (#​3049)

Contributors

We'd like to thank all the contributors who worked on this release!

@​ofekshenawa, @​Cgol9, @​LINKIWI, @​shawnwgit, @​zhuhaicity, @​bitsark, @​vladvildanov, @​ndyakov

Full Changelog: redis/go-redis@v9.7.0...v9.7.1

sap/admission-webhook-runtime (github.com/sap/admission-webhook-runtime)

v0.1.59

Compare Source

v0.1.58

Compare Source

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

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

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.

sap/go-generics (github.com/sap/go-generics)

v0.2.28

Compare Source

v0.2.27

Compare Source

kubernetes/api (k8s.io/api)

v0.32.2

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

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

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

v0.17.2

Compare Source

What's Changed

Dependencies

New Contributors

Full Changelog: kubernetes-sigs/controller-tools@v0.17.1...v0.17.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 renovate bot added the dependencies label Feb 6, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 6, 2025
@renovate renovate bot changed the title fix(deps): update module github.com/sap/component-operator-runtime to v0.3.70 fix(deps): update non-minor dependencies Feb 8, 2025
@renovate renovate bot force-pushed the renovate/non-minor-deps branch from ee119be to b632925 Compare February 8, 2025 04:32
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 8, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 10, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 10, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 11, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 11, 2025
@renovate renovate bot force-pushed the renovate/non-minor-deps branch 2 times, most recently from cb13efd to 099f6db Compare February 13, 2025 02:15
@renovate renovate bot force-pushed the renovate/non-minor-deps branch from 099f6db to f087358 Compare February 13, 2025 10:35
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 13, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 13, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 13, 2025
@renovate renovate bot force-pushed the renovate/non-minor-deps branch from ecd5c89 to 5127f4d Compare February 17, 2025 16:09
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 17, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 17, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 18, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 18, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 19, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 19, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 19, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 20, 2025
renovate-approve[bot]
renovate-approve bot previously approved these changes Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants