Per project containers

[kalikiana]

Right now there’s two ways to use snapcraft:

• Run snapcraft to build natively on the host machine - some features only work if the host is Ubuntu (based).
• Use cleanbuild which creates a temporary LXD container - the only supported workflow is equivalent to running “snapcraft” in a clean environment where everything except for the resulting .snap is discarded afterwards.

I’m introducing a third option:

• Allow executing all snapcraft commands in a persistent LXD container that is automatically created and mounts the project folder instead of using a one-off tarball.
• The host isn’t altered in any way and it doesn’t matter if it’s Ubuntu or something else.
• Iterative development becomes feasible even if the container is on another machine in the cloud.
• The use of containers is opaque, the workflow is the same as native.

For starters the new mode is hidden behind an environment variable - eventually there will be a prompt to ask the user if a container should be used for everything.

SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft

[sergiusens]

Here’s one of the PRs that will get this going generally: https://github.com/snapcore/snapcraft/pull/1263

[sergiusens]

It is worthy to note that we only have this support sort of ready for when the lxd remote is local. We need to discuss with @tvoss or @stgraber on how to deal with real remotes. The shuffled options we threw to the air were:

• ssh fuse
• nfs

I personally prefer the former given the ubiquity even if it means a performance hit.

[kalikiana]

I was talking to @stgraber and he’s suggested sshfs. I started looking into it and my primary concern to start with was having to setup something on the host that couldn’t be easily automated or undone; there seems to be a way, though, to ssh into the container with sftp-server on the machine running snapcraft. On the other hand nfs seems to require setup on the host and I’ve read about kernel limitations requiring a priviledged container.

[kalikiana]

I realize I never posted my findings from looking at existing solutions here.

• Vagrant can use nfs, rsync or smb or sshfs via a plugin either in host or slave mode.
• Docker allows basic sharing of the user’s home out of the box, backed by smb, osxfs (no source code available apparently) or VirtualBox guest additions depending on the host and tool used. Superuser privileges are required to share other folders via smb.

[bashfulrobot]

When using this option, I could see that the lxd container was stopped. But on the next run (without closing the terminal), it spun up a new container. How do you leverage the previous container?

My steps were:

SNAPCRAFT_CONTAINER_BUILDS=1
snapcraft cleanbuild

Then on rerun, simply:

snapcraft cleanbuild

Thanks!

[Saviq]

Don’t use cleanbuild, just snapcraft. By saying cleanbuild you’re actually instructing snapcraft to create a clean container every time.

[bashfulrobot]

Yeah, I was trying to keep my host system clean (installing deps, etc).

[kalikiana]

What SNAPCRAFT_CONTAINER_BUILDS=1 does is it enables regular commands to create a LXD container that’s persistent. So you can do snapcraft pull or snapcraft clean -s build mypart and it works inside the container (note: snapcraft update doesn’t work yet).

[bashfulrobot]

Thanks for clarification!

[kalikiana]

For those following this topic, there’s more improvements on the way:

• Wait on apt locks before running commands
• clean with no parts should only delete the container