anago: Push deb/rpm packages as part of the release process

[jimmycuadra]

/etc/apt/sources.list.d/kubernetes.list:

deb http://apt.kubernetes.io/ kubernetes-xenial main

In a shell:

$ sudo apt-get update
$ sudo apt-get install kubelet
Reading package lists... Done
Building dependency tree
Reading state information... Done
kubelet is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
$ kubelet --version
Kubernetes v1.6.6

It seems that has happened with previous releases: #263. This should be added to a release checklist, or ideally, automated.

[praseodym]

v1.7.0 packages are now available: https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/binary-amd64/Packages

[jimmycuadra]

There still seems to be a problem with the repositories getting updated when a new Kubernetes release is made. v1.7.2 was released 2 days ago but the apt repo still has only v1.7.1.

[jimmycuadra]

Any update on getting this part of the release process fixed? 1.8 has been released by the apt repo isn't updated.

[luxas]

This will be done very soon, I hope you understand @jimmycuadra that after a 14+ hour day for most of us (and unexpected problems with the pushing process), this part was deferred a couple of hours to today. Will be done in the coming hours.

If you want to dig into the releasing scripts in this repo, feel free to, this is open source 😉

cc @jdumars

[luxas]

This is now done, both debs and rpms are pushed.

[jimmycuadra]

I apologize that my tone made this issue sound demanding—that's not what I intended. I just wanted to track the fact that updates to the apt repo are not currently automated or tied to the release process of the binaries, so there is no way for people installing/updating k8s through the apt repo to know when it's actually ready besides just trying and seeing if an update is found.

I think this issue should be reopened to track the fact that this is still the case in general (I changed the title to make it clear that it's not about a specific k8s version being released.) I appreciate that the repo is open source and anyone can work on fixing this. I think there is still value in the issue being open so folks interested in contributing can see that it's something to be addressed. In other words, this can be used as a tracking issue, separate from a PR implementing improvements.

[luxas]

ok, I can reopen this then. I think @timothysc is planning to do this for v1.8, right?

[jdumars]

@jimmycuadra , I wasn't at all concerned about tone or anything. This is a very important part of the release process, and has been something that's slipped off the radar many times. As @luxas said, @timothysc has generously offered to look into the effort required to get this done. So, we basically have a dream team of engineering solving this now. How cool is that?

[praseodym]

I'm not seeing deb packages for v1.7.6 and v1.7.7. It would be great if these could be released as well!

Also, because Docker versions 1.12.6, 1.13.1, and 17.03.2 are newly validated for Kubernetes 1.8, maybe these versions could be added to the apt repository? Currently only docker-engine 1.11.2 is available there.

[colemickens]

Not to keep piling on (this is something I'd like to circle back on eventually and help with as well), but kubernetes-cni is alos behind the releases from the containernetworking plugins repository. Not sure if it's supposed to be updated as there are new CNI releases. Also, not sure if releases for CNI are managed through this repo, but I'm assuming kubernetes-cni package issues go here at least.

[luxas]

@colemickens CNI releases are tied to a specific k8s release. We're bumping the CNI version in v1.9 to v0.6: kubernetes/kubernetes#51250 (comment)

[timothysc]

@luxas lets enqueue this for @kubernetes/sig-cluster-lifecycle-feature-requests next week.

[fejta-bot]

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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[fejta-bot]

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-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[colemickens]

/remove-lifecycle rotten
/reopen

[k8s-ci-robot]

@colemickens: you can't re-open an issue/PR unless you authored it or you are assigned to it.

In response to this:

/remove-lifecycle rotten
/reopen

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.

[jdumars]

re-opening per @colemickens

[jdumars]

/sig release

[jdumars]

/sig cluster-lifecycle

[luxas]

Let's track this only in one place. This is a duplicate of kubernetes/sig-release#10, where I think the release team actually tracks issues to be fixed these days. Correct me if I'm wrong @jdumars