Hey, I’m wondering about the reason behind the move to multipass: What is the advantage of dropping LXC/LXD for multipass (which is basically a cli tool for QEMU, if I understand it correctly) instead of switching to a cross-platform container-based solution like Docker for example?
Would love to understand the reasoning behind this move, since I couldn’t find much information about it.
The release notes say that multipass will “[guarantee] more consistent results when builds are run from different machines”. What kind of consistency issues occurred with LXD? Thanks 
1 Like
A minor (actually fairly major) point. Multipass is also cross platform. It’s available for Linux, macOS and Windows. 
1 Like
True! I think multipass is great on its own.
I just don’t understand its advantage for snapcraft, yet. The question that remains for me is what kind of improvement a full blown QEMU VM brings in comparison to a cross-platform container-based solution (e.g. Docker) for snapcraft builds
One though - you can install the snapcraft tool I believe on OS X to build snaps from (not for) OSX. (IIRC)
Excellent question, @TimSueberkrueb, thanks for bringing it up. Before I say anything else, note that LXD support will be returning with feature parity with multipass-- virtualization just doesn’t work everywhere.
That said, why the virtualization route in the first place? This revolves around the introduction of bases. A fundamental question we needed to answer last cycle was: how should a snap with base: core be built differently from a snap with base: core18, and differently from a snap with base: fedora (if that existed)? The answer was challenging, particularly when you consider that changing the base also needed to affect stage-packages and build-packages, along with the fact that snapcraft is a cross-platform tool (across Linux distributions is challenging enough, then throw in OSX, etc.). What should happen if you try to build a base: core18 snap when running on Fedora? Or a base: fedora snap when running on Ubuntu? Even simpler: what should happen if building a base: core18 snap on Xenial?
The only solution that seemed to cover all the requirements here was to have snapcraft use a different operating system for building depending on the base. The initial idea was to use a LXD image per base, but then we realized that specific kernel features are required in order to use build-snaps, and LXD sits on top of the host kernel (as does Docker, although Docker has other issues preventing it from running snaps, too). Thus we arrived at multipass as the only sure-fired way to make sure folks were building on an image that would definitely build snaps, and it also ensures that machine A is building snaps in the same way as machine B.
8 Likes
Thanks for this excellent explanation. This makes 100% sense. I think you should just copy your answer and make a doc entry out of it 
Also glad to hear that LXD is coming back. Thank you
4 Likes
I noticed that building with multipass and docker produces different results and only snap which produced by multipass works correctly
So as far as I understood there is no way to build snap with docker, right?
No, you can still build with docker, see https://docs.snapcraft.io/build-on-docker
If you are running into issues with snaps built from docker vs multipass not working the same you should start a new topic on that.