-
Notifications
You must be signed in to change notification settings - Fork 502
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
rpm: Update CNI to v0.8.3 #731
Conversation
/cc @kubernetes/patch-release-team @kubernetes/release-managers @kubernetes/release-engineering |
/cc @sumitranr |
Do we need to upgrade |
/hold We need test evidence that this actually integrates (cluster lifecycle, scalability?). |
No, the plugins and CNI libraries are independent. |
/assign @claurence |
@justaugustus given how close we are to the release for 1.15 I'm very hesitant to want to include this given CI Signal is stabilizing and I have concerns around risk this would add especially without info from SIG Scalability Is there a reason we would really want to include this in the 1.15 release? if there is a very compelling reason (i.e. security) let me know - if not I'd want to defer for either a patch or 1.16 |
@tpepper / @claurence -- don't get me wrong; I get where you're coming from, but this might be endemic of a more sinister problem... Do we ever have signal from the packages we cut? |
There are several issues that suggest that we are not doing a great job of understanding this / exercising the toolchain:
One of the questions in my mind is do we halt bumping/building packages (which may introduce security/bug fixes) because we're lacking signal or do we try to solve both problems at once? I would argue that that's not a good reason to hold this up. Given the tooling we have today, we're only going to understand how these pieces work together after we build them. |
The CNI plugins included here are used as part of kubenet. There haven't been any improvements in v0.8 that have to go in 1.15. So there's no need to rush this. |
While I totally understand the desire to move quickly I don't have enough confidence this won't impact our release date and given the proximity to kubecon shanghai I'd like to keep things stable Is there a reason this can't wait for a patch to go in? The urgency for this is not clear to me |
Yes and no. Almost all the time we have an associated SIG coming saying please update this dependency. On average the folks closest to each dependency make the argument for why the project should rev the dependency. Here I'd think that would be SIG Networking and SIG Cloud Provider and their subsidiary sub-projects making the push to change, with follow on vetting by SIG Release to insure the change timing makes sense and it doesn't surprise folks in SIG Cluster Lifecycle and SIG Scalability for example. It will be awesome to have automation observing new versions of our machine readable dependency set and automatically pushing the changed set into a feature branch for full test validation. We will get there. In the meantime we have a lot of manual caution and discussion required. |
@tpepper / @claurence / @squeed -- yep, you're totally right that this is not something that needs to land now. I think I'm just expressing general frustration that this isn't something we can do today / is something that needs to be gated on release timing. I will code in anger to fix this 😝 |
/milestone 1.16 |
@justaugustus: Adding label: Reasons for blocking this PR:[Changes to certain release tools can affect our ability to test, build, and release Kubernetes. This PR must be explicitly approved by SIG Release repo admins.] Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Bumped to |
@justaugustus: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justaugustus The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Stephen Augustus <saugustus@vmware.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM :)
should we move this to 1.18? |
/milestone v1.18 |
CNI 0.8.4 is out, but we're in the process of refactoring the rpm tooling in #1027, so I'm closing this out for now. /close |
@justaugustus: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@justaugustus: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
A new version (
v0.8.2v0.8.3) of CNI plugins has been released.We're updating the
deb package definitionand rpm spec to use v0.8.3 in this PR.ref:
(thanks @squeed!)
/kind feature
/priority important-soon
/milestone v1.17