sig-release
sig-release copied to clipboard
CNI plugins (kubernetes-cni) build and packaging process improvements
Originally opened by @rdodev:
Presently both
bazel
builds and release-related scripts build debs and rpms via a tarball downloaded from google object store. I've not seen or found any documentation or code that explains how this tarball is built. Would like if not the script(s) used to build and create the tarball at least a detailed description how to go about manually building it.
Action items
Release Engineering
- [x] (@thockin - https://github.com/kubernetes/k8s.io/pull/553) Create a GCS bucket with shared control between CNI plugin maintainers and Release Engineering
- [x] (@justaugustus - ~https://github.com/kubernetes/kubernetes/pull/87562~ https://github.com/kubernetes/kubernetes/pull/78819) Update CNI fetch URLs in k/k to use new GCS bucket (
gs://k8s-artifacts-cni
) - [x] (@justaugustus - https://github.com/kubernetes/kubernetes/pull/78819) Update CNI plugins to v0.8.5 in k/k
- [x] (@justaugustus - https://github.com/kubernetes/k8s.io/pull/591) Update membership to IAM group for CNI (
[email protected]
) once CNI maintainers are updated - https://github.com/kubernetes/k8s.io/blob/c72a701bf6602560efbdaa0bb717f34c14f80a3f/groups/groups.yaml#L290-L299 - [ ] (@justaugustus) Update Release Engineering documentation on CNI
- [x] (@justaugustus - https://github.com/kubernetes/release/pull/1311) Support publishing GH releases to GCS buckets - gh2gcs
- [x] (@justaugustus - https://github.com/kubernetes/release/pull/1309) Move CNI plugins into
kubelet
deb/rpm package and deprecatekubernetes-cni
deb/rpm package - https://github.com/kubernetes/release/issues/885
CNI plugins maintainers (https://github.com/containernetworking/plugins/issues/446)
- [x] (https://github.com/containernetworking/plugins/pull/454, https://github.com/containernetworking/cni/pull/752) Update repo owners/maintainers (usernames and email addresses)
- [x] Make decision on whether to dual-publish release artifacts (GitHub + Kubernetes GCS) or just to Kubernetes GCS (
gs://k8s-artifacts-cni/release/
)- Planning to dual-publish (ref: https://github.com/containernetworking/plugins/issues/446#issuecomment-588309522)
- [ ] Update release scripts to support publishing to GCS
- [ ] Update release documentation
Can someone pick this up? /help ping @kubernetes/sig-release-feature-requests
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Given lack of engagement on this ticket, I'm going to close it.
...well this seems like something we still need to do given last cycle's kerfuffle. /reopen /remove-lifecycle stale /milestone v1.15 /priority important-soon
@justaugustus: Reopened this issue.
In response to this:
...well this seems like something we still need to do given last cycle's kerfuffle. /reopen /remove-lifecycle stale /milestone v1.15 /priority important-soon
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.
/assign /remove-help /milestone v1.16
@rdodev -- there's a divergence between the tools we exercise in tests (https://github.com/kubernetes/kubernetes/tree/master/build) and the ones that actually build/publish packages (https://github.com/kubernetes/release/tree/master/debian, https://github.com/kubernetes/release/tree/master/rpm).
Currently, kubernetes-cni
releases can only be built/published while cutting a Kubernetes release. It's an "all-or-nothing" for the following packages:
- kubeadm
- kubelet
- kubectl
- kubernetes-cni
- cri-tools
@tpepper and I are working on detangling some of the existing stuff here:
- https://github.com/kubernetes/release/pull/734
- https://github.com/kubernetes/release/pull/693
Both PRs should enable building individual packages, instead of the whole suite. Once that settles out, I'll double-back and document the process.
/area release-eng
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
/remove-lifecycle stale
@cpanato we maybe can add this to our documentation work
We're going to be moving kubernetes-cni
into the kubelet
package.
I should be able to wrap this up in 1.18.
/milestone v1.18 ref: https://groups.google.com/d/topic/kubernetes-sig-release/yhf7hAqJEN0/discussion
SIG Network (@kubernetes/sig-network-misc) -- Who are the best owners for the "CNI plugins maintainers" tasks listed in the issue description?
/assign @thockin @dcbw @caseydavenport /remove-priority important-soon /priority critical-urgent
Btw. I'm also interested in that who should be notified on kubernetes side in case of creating new release of cni plugins, as week ago I didn't had this information while I was publishing new release.
Is there a cni-announce mailing list?
@dcbw and @squeed and @bboreham have historically bridged the worlds, but it has not been formalized in k8s-space.
well, Github allows to subscribe to the repository and watch for "releases only", at least is how I'm doing it https://github.com/containernetworking/plugins/releases
There is a cni-dev mailing list which is extremely low volume, and CNI release instructions say to announce on that.
Since it seems to be an issue we could think about bringing the keep this up-to-date responsibility for those tools into SIG release (engineering). cri-tools has more or less the same problem domain like CNI.
FYI @huchengze @ydcool (ref: https://github.com/kubernetes/kubernetes/issues/87228#issuecomment-580330485)
Btw. I'm also interested in that who should be notified on kubernetes side in case of creating new release of cni plugins, as week ago I didn't had this information while I was publishing new release.
@kubernetes/release-engineering -- Can you please subscribe to CNI dev mailing list to keep track of CNI plugin releases?
I personally also watch the releases on https://github.com/containernetworking/plugins and would suggest doing the same.
@dcbw @squeed @bboreham @jellonek -- Would it be possible to also do pre-announces in addition to cc-ing [email protected]
on CNI plugins release announcements?
Since it seems to be an issue we could think about bringing the keep this up-to-date responsibility for those tools into SIG release (engineering). cri-tools has more or less the same problem domain like CNI.
@saschagrunert -- Yes, that's exactly the plan. I've got a nearly identical issue opened for CRI tools. Once we find a good workflow on the CNI plugins side, we can plan to replicate that for cri-tools. :)
I've opened a corresponding issue for the CNI plugins maintainers tasks in their repo: https://github.com/containernetworking/plugins/issues/446
PR to bundle CNI plugins in the kubelet apt/yum packages: https://github.com/kubernetes/release/pull/1309
Putting this back in progress. Hoping to close the books on this in v1.20.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
/remove-priority critical-urgent /priority important-soon /remove-lifecycle rotten
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten