Investigate using snap packages

[castrojo]

http://snapcraft.io/

It would be nice to have atomic operations for packaging as well as the ability to publish to an edge channel (perhaps per commit in master?), rollbacks, and other features.

I can find someone to help mentor.

[mikedanese]

cc @mansoorj @kelseyhightower @kubernetes/sig-cluster-lifecycle

[rothgar]

Sadly these cross-distro packaging solutions have almost as many variations as their distro specific packaging managers.

• AppImage
• Flatpak
• Nix <- not exactly the same

What is the scope or desire for using snap (or similar) to package Kubernetes releases? Easier installation?

I don't understand the benefit of snap over a statically compiled binary and/or running inside containers which are already cross distro "packages". I'm not trying to say it's a bad idea, I just don't understand it.

[castrojo]

Chuck covered this in the sig-cluster-lifecycle call so I'll add the responses here as well as clarify some of the other ones we mentioned since we were running out of time:

• Atomic commits are becoming increasingly important to our users, it would be nice to give people a bare-metal end-to-end kubernetes deployment with transactional packaging (including rollback).
  • In the future people can do nodes with nothing but a bare ubuntu-core transactional image (~100mb) and the kubernetes snap on top.
• Channels directly to end users. This would give us the ability to do direct-from-upstream kubernetes publishing into edge, beta, candidate, and stable channels.
  • These channels are enabled by default (at least on Ubuntu), which means the user doesn't need to know/understand 3rd party repositories, they can just be on the delivery end of the kubernetes snap channel.
  • The kubernetes snaps would publish at the same time as release.
• We can pack all the dependencies (including docker itself if need be) into one snap.
• Snaps run confined via apparmor, we would need to investigate how this relates to the confinement plans for k8s 1.4.

I can't speak about the other cross-distro packaging formats other than they appear to be desktop specific and not something you'd run on a cloud.

As discussed in the meeting, we'll work on a PR to kick off this work, thanks!

[rothgar]

I'm ignorant about the release process. Reading through some of this repo didn't explain the following questions so maybe someone can help

• Are other packages built from the official kubernetes release? (deb, rpm) I thought it was only static binaries and .tar.gz that was produced.
• If other packages are automatically created, how do those packages get pushed into their respective repos for the distro?
• if not, why would the kubernetes release team want to build and maintain snap packages in kubernetes? (I assumed those were distro/project maintainer responsibilities)

[rothgar]

@castrojo Thanks for including the notes. This makes a lot of sense to me if docker is bundled with the snap. It could easily keep compatible version of docker + kubelet together.

I have not tried snap myself so I'll need to play with how it works if I have docker on the host and then install/run a snap isolated docker daemon on the same system.

[lazypower]

@rothgar in reply to "if i have docker on the host then install a snap isolated daemon" You'll have to ensure the docker socket is inside the sandbox, or make a privileged snap so it can modify files outside of its isolated sandbox. Then it's the exact same principal as having a bootstrap docker daemon vs a workload docker daemon. The separate daemon approach was mentioned in the running kubernetes in docker guides.

[david-mcmahon]

@rothgar This repo was setup to hold the release automation tooling wrapping the build tooling that exists in kubernetes/kubernetes and to handle all of the pushing, notifying, and release notes gathering around kubernetes releases.

It is expected that functionality will grow with contributions and we will use this repo to hold all things release and packaging related.

The build scripts in kubernetes/kubernetes do not currently produce other types of packaging (dev, rpm). There is an open PR in this repo exploring the possibility.

[errordeveloper]

kubelet has many dependencies, as documented in kubernetes/kubernetes#26093, so it'd be good to understand if all of those can be snapped-up.

[lazypower]

Ah! This is very helpful @errordeveloper. Thanks for the detailed callout of what we'll need to consider for the snaps. I'll take this list and confer with some of the snappy devs to ensure we can accommodate this list.

We'll spike on a first draft of what this looks like on Tuesday, and see where we end up. That'll give us a good first go at where we fell down if so, and what would need to be done .

[luxas]

Any progress on this?

[lazypower]

We did some initial investigation. There is a docker plug being written that will unblock this effort.

But today it's still a no go

[mikedanese]

Fyi, snap support proposed in #293

[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

[errordeveloper]

/close

Closing in favour of #293.