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::namedeprecationA consequence of all the policy writing and the improved clarity we have decided to deprecate the common
ResourceExt::namehelper.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_anyfor a general identifier:-pod.name() +pod.name_any()What's Changed
Added
- Add support for passing the
fieldValidationquery parameter on patch by@phroggyyin kube-rs/kube-rs#929- Add
conditions::is_job_completedby@cluxin kube-rs/kube-rs#935Changed
- Deprecate
ResourceExt::namein favour of safe name_* alternatives by@cluxin kube-rs/kube-rs#945Removed
- Remove
#[kube(apiextensions)]flag fromkube-deriveby@cluxin kube-rs/kube-rs#920Fixed
- Document every public derived fn from kube-derive by
@cluxin kube-rs/kube-rs#919- fix applier hangs which can happen with many watched objects by
@moustafabin kube-rs/kube-rs#925- Applier: Improve reconciler reschedule context to avoid deadlocking on full channel by
@teozkrin kube-rs/kube-rs#932- Fix deserialization issue in AdmissionResponse by
@cluxin kube-rs/kube-rs#939- Admission controller example fixes by
@Alibirbin kube-rs/kube-rs#950New Contributors
@moustafabmade their first contribution in kube-rs/kube-rs#925@phroggyymade their first contribution in kube-rs/kube-rs#929@Alibirbmade 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::namedeprecationA consequence of all the policy writing and the improved clarity we have decided to deprecate the common
ResourceExt::namehelper.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_anyfor a general identifier:-pod.name() +pod.name_any()What's Changed
Added
- Add support for passing the
fieldValidationquery parameter on patch by@phroggyyin kube-rs/kube#929- Add
conditions::is_job_completedby@cluxin kube-rs/kube#935Changed
- Deprecate
ResourceExt::namein favour of safe name_* alternatives by@cluxin kube-rs/kube#945Removed
- Remove
#[kube(apiextensions)]flag fromkube-deriveby@cluxin kube-rs/kube#920Fixed
- Document every public derived fn from kube-derive by
@cluxin kube-rs/kube#919- fix applier hangs which can happen with many watched objects by
@moustafabin kube-rs/kube#925- Applier: Improve reconciler reschedule context to avoid deadlocking on full channel by
@teozkrin kube-rs/kube#932- Fix deserialization issue in AdmissionResponse by
@cluxin kube-rs/kube#939- Admission controller example fixes by
@Alibirbin kube-rs/kube#9500.73.1 / 2022-06-03
Highlights
This patch release fixes a bug causing
applierandControllerto deadlock when too many Kubernetes object change events were ingested at once. All users ofapplierandControllerare 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
2baa3aerelease 0.74.0a7ebe6ddocs: clarify that is_crd_stablished does not imply discovery done (#951)04c3578Admission controller example fixes (#950)55bea0bDeprecate ResourceExt::name in favour of safe name_* alternatives (#945)9f1df5eFix deserialization issue in AdmissionResponse (#939)f99140eRun e2e,integration tests against supported kubernetes versions (#924)4bb19fbAdd conditions::is_job_completed (#935)9366e0crustfmt (#934)c37d07bAdd support for passing the fieldValidation query parameter on patch (#929)12218edMerge 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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill 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 versionwill 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 dependencywill 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.