bottlerocket-update-operator
bottlerocket-update-operator copied to clipboard
Bump kube from 0.71.0 to 0.74.0
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:
- We have codified our Kubernetes versioning policy
- The Rust version policy has extended its support range
- Our CI has been extended
ResourceExt::name
deprecationA 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 newResourceExt::name_any
for a general identifier:-pod.name() +pod.name_any()
What's Changed
Added
- Add support for passing the
fieldValidation
query parameter on patch by@phroggyy
in kube-rs/kube-rs#929- Add
conditions::is_job_completed
by@clux
in kube-rs/kube-rs#935Changed
- Deprecate
ResourceExt::name
in favour of safe name_* alternatives by@clux
in kube-rs/kube-rs#945Removed
- Remove
#[kube(apiextensions)]
flag fromkube-derive
by@clux
in kube-rs/kube-rs#920Fixed
- Document every public derived fn from kube-derive by
@clux
in kube-rs/kube-rs#919- fix applier hangs which can happen with many watched objects by
@moustafab
in kube-rs/kube-rs#925- Applier: Improve reconciler reschedule context to avoid deadlocking on full channel by
@teozkr
in kube-rs/kube-rs#932- Fix deserialization issue in AdmissionResponse by
@clux
in kube-rs/kube-rs#939- Admission controller example fixes by
@Alibirb
in kube-rs/kube-rs#950New Contributors
@moustafab
made their first contribution in kube-rs/kube-rs#925@phroggyy
made their first contribution in kube-rs/kube-rs#929@Alibirb
made their first contribution in kube-rs/kube-rs#950Full 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:
- We have codified our Kubernetes versioning policy
- The Rust version policy has extended its support range
- Our CI has been extended
ResourceExt::name
deprecationA 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 newResourceExt::name_any
for a general identifier:-pod.name() +pod.name_any()
What's Changed
Added
- Add support for passing the
fieldValidation
query parameter on patch by@phroggyy
in kube-rs/kube#929- Add
conditions::is_job_completed
by@clux
in kube-rs/kube#935Changed
- Deprecate
ResourceExt::name
in favour of safe name_* alternatives by@clux
in kube-rs/kube#945Removed
- Remove
#[kube(apiextensions)]
flag fromkube-derive
by@clux
in kube-rs/kube#920Fixed
- Document every public derived fn from kube-derive by
@clux
in kube-rs/kube#919- fix applier hangs which can happen with many watched objects by
@moustafab
in kube-rs/kube#925- Applier: Improve reconciler reschedule context to avoid deadlocking on full channel by
@teozkr
in kube-rs/kube#932- Fix deserialization issue in AdmissionResponse by
@clux
in kube-rs/kube#939- Admission controller example fixes by
@Alibirb
in kube-rs/kube#9500.73.1 / 2022-06-03
Highlights
This patch release fixes a bug causing
applier
andController
to deadlock when too many Kubernetes object change events were ingested at once. All users ofapplier
andController
are encouraged to upgrade as quickly as possible. Older versions are also affected, this bug is believed to have existed since the original release ofkube_runtime
.
... (truncated)
Commits
2baa3ae
release 0.74.0a7ebe6d
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 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)
Hmmmm lots of conflicts in this one - we'll need to probably do this one manually as well 🤔
There are a few interrelated crates that need to be bumped at the same time.
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?
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 🎈
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.
Looks like kube is up-to-date now, so this is no longer needed.