keep apt.kubernetes.io up to date about release

[mikedanese]

1.5.0 has a security vulerability so we are waiting for v1.5.1. We have not yet fixed this issue so our deb versions don't follow release versions to the tee. We hope to fix that. That's why this issue is open.

[mikedanese]

Ok, I see. I can do that.

[dawidmalina]

When we can expect packages for kubernetes v1.4.7?

[luxas]

The stable packages are going to be updated to v1.5.0 today or tomorrow

[dawidmalina]

I understand 1.5.0 when it will be released but what with 1.4.x branch? Are you going to abandoned it? Does it mean that you will only publish cherry picked versions not all released versions? What are the criteria (which version will be put to apt.kubernetes.io)?

[dawidmalina]

What are the reasons to have only limited set of packages?

[dawidmalina]

Any update?

[luxas]

Sent #237 to fix this

[autostatic]

I see there are new updates available but those are packages from the 1.5 branch. Would it be possible to also add updated 1.4 packages?
I also see kubeadm 1.6.0-alpha got pulled in while I thought that kubernetes-xenial was the stable repo. Or is this version of kubeadm considered stable?

[luxas]

I also see kubeadm 1.6.0-alpha got pulled in while I thought that kubernetes-xenial was the stable repo. Or is this version of kubeadm considered stable?

yes, that version of kubeadm is stable. ref kubernetes/kubeadm#70

in time for v1.6, we'll sync up the releases with the core

[luxas]

@mikedanese Can you create the nightly channel yet so this issue will be fully fixed?

Stable and unstable are already tracking latest and stable.txt, so the original issue is fixed I think.

[mikedanese]

Nightly debs are available for amd64 but not published. you can curl them and dpkg -i followed by a apt-get install -f. Doing more then that is not high on my priority list right now.

[luxas]

I mean I implemented that nightly functionality for all arches and everything in #237, so could you just make those deb repos (only for kubernetes-xenial is totally ok also) and say to your deb CI script that it will also upload the nightly channel that already is generated?

[luxas]

Thank you

[luxas]

@mikedanese ping on a nightly channel for debs (not super-priority, but went through my issues and found this)

[alexlist]

Hi,

would you mind providing

1. a working source apt repo for Ubuntu Xenial

https://packages.cloud.google.com/apt/dists/kubernetes-xenial/main/source/Sources exists but is empty

2. both binary and source reops for Debian jessie anytime soon? Stretch would be nice as well, as that's most likely going to be released within a month or so...

https://packages.cloud.google.com/apt/dists/kubernetes-jessie/main/binary-amd64/Packages exists but is empty
https://packages.cloud.google.com/apt/dists/kubernetes-jessie/main/source/Sources exists but is empty

Thank you!

Alex

[mikedanese]

1. The problem is that we don't build debian packages from source and it would be a significant change to our buildsystem to do so. @luxas might have some thoughts.
2. Jessie is tricky because they don't enable the memory cgroup by default which we can't run without and requires a kernel boot parmeter to change.

[geekofalltrades]

I would love to upgrade to 1.5.6 then 1.6.0 over the next couple days, but the latest version in the apt repo is still 1.5.2...

[geekofalltrades]

For anyone looking for a workaround, I just successfully ran the deb build myself: https://github.com/kubernetes/release/blob/master/README.md#for-debian

I was able to build only for Xenial amd64 (I only need that, rather than all builds) by running docker run --volume="$(pwd)/debian:/src" debian-packager -arch amd64 -distros xenial.

My company happens to have an internal reprepo apt repository where I can host them.

[luxas]

This will happen when kubernetes/sig-release#10 is implemented.
To publish these packages is not a priority. You can build them yourself easily with docker though