bottlerocket-update-operator icon indicating copy to clipboard operation
bottlerocket-update-operator copied to clipboard

Bump kube from 0.71.0 to 0.74.0

Open dependabot[bot] opened this issue 1 year ago • 5 comments

Bumps kube from 0.71.0 to 0.74.0.

Release notes

Sourced from kube's releases.

0.74.0

Highlights

Polish, bug fixes, guidelines, ci improvements, and new contributors

This release features smaller improvements/additions/cleanups/fixes, many of which are from new first-time contributors! Thank you everyone! The listed deadlock fix was backported to 0.73.1.

We have also been trying to clarify and prove a lot more of our external-facing guarantees, and as a result:

ResourceExt::name deprecation

A consequence of all the policy writing and the improved clarity we have decided to deprecate the common ResourceExt::name helper.

This method could panic and it is unexpected for the users and bad for our consistency. To get the old functionality, you can replace any .name() call on a Kubernetes resources with .name_unchecked(); but as the name implies, it can panic (in a local setting, or during admission). We recommend you replace it with the new ResourceExt::name_any for a general identifier:

-pod.name()
+pod.name_any()

What's Changed

Added

Changed

Removed

Fixed

New Contributors

Full Changelog: https://github.com/kube-rs/kube-rs/compare/0.73.0...0.74.0

0.73.1

Highlights

... (truncated)

Changelog

Sourced from kube's changelog.

0.74.0 / 2022-07-09

Highlights

Polish, bug fixes, guidelines, ci improvements, and new contributors

This release features smaller improvements/additions/cleanups/fixes, many of which are from new first-time contributors! Thank you everyone! The listed deadlock fix was backported to 0.73.1.

We have also been trying to clarify and prove a lot more of our external-facing guarantees, and as a result:

ResourceExt::name deprecation

A consequence of all the policy writing and the improved clarity we have decided to deprecate the common ResourceExt::name helper.

This method could panic and it is unexpected for the users and bad for our consistency. To get the old functionality, you can replace any .name() call on a Kubernetes resources with .name_unchecked(); but as the name implies, it can panic (in a local setting, or during admission). We recommend you replace it with the new ResourceExt::name_any for a general identifier:

-pod.name()
+pod.name_any()

What's Changed

Added

Changed

Removed

Fixed

0.73.1 / 2022-06-03

Highlights

This patch release fixes a bug causing applier and Controller to deadlock when too many Kubernetes object change events were ingested at once. All users of applier and Controller are encouraged to upgrade as quickly as possible. Older versions are also affected, this bug is believed to have existed since the original release of kube_runtime.

... (truncated)

Commits
  • 2baa3ae release 0.74.0
  • a7ebe6d docs: clarify that is_crd_stablished does not imply discovery done (#951)
  • 04c3578 Admission controller example fixes (#950)
  • 55bea0b Deprecate ResourceExt::name in favour of safe name_* alternatives (#945)
  • 9f1df5e Fix deserialization issue in AdmissionResponse (#939)
  • f99140e Run e2e,integration tests against supported kubernetes versions (#924)
  • 4bb19fb Add conditions::is_job_completed (#935)
  • 9366e0c rustfmt (#934)
  • c37d07b Add support for passing the fieldValidation query parameter on patch (#929)
  • 12218ed Merge pull request #932 from teozkr/bugfix/issue-926
  • Additional commits viewable in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependabot[bot] avatar Oct 11 '22 21:10 dependabot[bot]

Hmmmm lots of conflicts in this one - we'll need to probably do this one manually as well 🤔

jpmcb avatar Oct 12 '22 18:10 jpmcb

There are a few interrelated crates that need to be bumped at the same time.

webern avatar Oct 12 '22 21:10 webern

I looked at upgrading these manually but it seems most of the conflicts are coming out of the aws-* creates which have slightly older dependencies compared to the kube crate. Example:

error[B004]: found 2 duplicate entries for crate 'webpki'
    ┌─ /src/Cargo.lock:322:1
    │  
322 │ ╭ webpki 0.21.4 registry+https://github.com/rust-lang/crates.io-index
323 │ │ webpki 0.22.0 registry+https://github.com/rust-lang/crates.io-index
    │ ╰───────────────────────────────────────────────────────────────────^ lock entries
    │  
    = webpki v0.21.4
      ├── hyper-rustls v0.22.1
      │   └── aws-smithy-client v0.49.0
      │       ├── aws-config v0.49.0
      │       │   └── integ v0.1.0
      │       ├── aws-sdk-ec2 v0.19.0
      │       │   └── integ v0.1.0 (*)
      │       ├── aws-sdk-eks v0.19.0
      │       │   └── integ v0.1.0 (*)
      │       ├── aws-sdk-iam v0.19.0
      │       │   └── integ v0.1.0 (*)
      │       ├── aws-sdk-ssm v0.19.0
      │       │   └── integ v0.1.0 (*)
      │       ├── aws-sdk-sso v0.19.0
      │       │   └── aws-config v0.49.0 (*)
      │       ├── aws-sdk-sts v0.19.0
      │       │   └── aws-config v0.49.0 (*)
      │       └── aws-types v0.49.0
      │           ├── aws-config v0.49.0 (*)
      │           ├── aws-endpoint v0.49.0
      │           │   ├── aws-sdk-ec2 v0.19.0 (*)
      │           │   ├── aws-sdk-eks v0.19.0 (*)
      │           │   ├── aws-sdk-iam v0.19.0 (*)
      │           │   ├── aws-sdk-ssm v0.19.0 (*)
      │           │   ├── aws-sdk-sso v0.19.0 (*)
      │           │   └── aws-sdk-sts v0.19.0 (*)
      │           ├── aws-http v0.49.0
      │           │   ├── aws-config v0.49.0 (*)
      │           │   ├── aws-sdk-ec2 v0.19.0 (*)
      │           │   ├── aws-sdk-eks v0.19.0 (*)
      │           │   ├── aws-sdk-iam v0.19.0 (*)
      │           │   ├── aws-sdk-ssm v0.19.0 (*)
      │           │   ├── aws-sdk-sso v0.19.0 (*)
      │           │   └── aws-sdk-sts v0.19.0 (*)
      │           ├── aws-sdk-ec2 v0.19.0 (*)
      │           ├── aws-sdk-eks v0.19.0 (*)
      │           ├── aws-sdk-iam v0.19.0 (*)
      │           ├── aws-sdk-ssm v0.19.0 (*)
      │           ├── aws-sdk-sso v0.19.0 (*)
      │           ├── aws-sdk-sts v0.19.0 (*)
      │           └── aws-sig-auth v0.49.0
      │               ├── aws-sdk-ec2 v0.19.0 (*)
      │               ├── aws-sdk-eks v0.19.0 (*)
      │               ├── aws-sdk-iam v0.19.0 (*)
      │               ├── aws-sdk-ssm v0.19.0 (*)
      │               ├── aws-sdk-sso v0.19.0 (*)
      │               └── aws-sdk-sts v0.19.0 (*)
      ├── rustls v0.19.1
      │   ├── hyper-rustls v0.22.1 (*)
      │   ├── rustls-native-certs v0.5.0
      │   │   └── hyper-rustls v0.22.1 (*)
      │   └── tokio-rustls v0.22.0
      │       └── hyper-rustls v0.22.1 (*)
      └── tokio-rustls v0.22.0 (*)
    = webpki v0.22.0
      ├── rustls v0.20.4
      │   ├── hyper-rustls v0.23.0
      │   │   └── kube-client v0.74.0
      │   │       ├── kube v0.74.0
      │   │       │   ├── agent v0.1.0
      │   │       │   ├── apiserver v0.1.0
      │   │       │   │   └── agent v0.1.0 (*)
      │   │       │   ├── controller v0.1.0
      │   │       │   ├── integ v0.1.0
      │   │       │   ├── models v0.1.0
      │   │       │   │   ├── agent v0.1.0 (*)
      │   │       │   │   ├── (dev) apiserver v0.1.0 (*)
      │   │       │   │   ├── apiserver v0.1.0 (*)
      │   │       │   │   ├── controller v0.1.0 (*)
      │   │       │   │   ├── (dev) integ v0.1.0 (*)
      │   │       │   │   ├── integ v0.1.0 (*)
      │   │       │   │   └── (build) yamlgen v0.1.0
      │   │       │   └── (build) yamlgen v0.1.0 (*)
      │   │       └── kube-runtime v0.74.0
      │   │           └── kube v0.74.0 (*)
      │   ├── kube-client v0.74.0 (*)
      │   └── tokio-rustls v0.23.3
      │       └── hyper-rustls v0.23.0 (*)
      └── tokio-rustls v0.23.3 (*)

Is there an idiomatic way to do this out of band of the individual crates? Or do we need to wait for the aws-* libraries to push an update with these newer dependencies in order to prevent a conflict?

jpmcb avatar Oct 13 '22 16:10 jpmcb

Happy day, looks like they just cut a release with upgraded dependencies: https://github.com/awslabs/smithy-rs/releases/tag/release-2022-10-13

Hopefully we can consume that and get these dependencies upgrade 🎈

jpmcb avatar Oct 13 '22 16:10 jpmcb

I think that error you pasted is from (what in my opinion is) an unnecessary lint. I think you can fix it with the cargo deny toml definition by allowing 2 versions of the offending crates to exist. The TL;DR is that multiple major versions of a crate is (usually) Ok in Rust, but we use cargo deny to bring it to our attention.

webern avatar Oct 13 '22 23:10 webern

Looks like kube is up-to-date now, so this is no longer needed.

dependabot[bot] avatar Oct 17 '22 21:10 dependabot[bot]