[DRAFT] LXD by default for Snapcraft when on Linux

snapcraft
1

Abstract

Backwards compatible change to Snapcraft’s current default provider (Multipass) to LXD when running on a Linux environment.

Rationale

Snapcraft today defaults to Multipass, as a default when running on native hardware, it provides the best experience for a common environment across all supported platforms (i.e.; Linux, Windows and OS X).

This however is a hindrance on machines with low RAM or systems that already run within a virtual environment, leading to having to deal with virtual machine nesting which is not as easy or straightforward to setup.

Multipass does not support the advanced storage options that allow for data deduplication nor does it support snapshots which have the potential of making the bootstrapping of an environment a lot smoother.

Open continuous integration systems would also benefit as those usually run inside constrained environments.

Specification

These are the premises for the specification:

  • Existing projects should not change
  • A change in snapcraft.yaml or user set toggle defines a new behavior.

This implies that Snapcraft should keep Multipass as the default for all existing projects and no unnoticed change will change this default. Existing projects that require LXD to be used shall keep using --use-lxd to make that so.

Historically, Snapcraft has made changes to defaults or build behaviors when the base was changed in snapcraft.yaml. Snapcraft can then do then select Multipass by default when the base is (or build-base):

  • core
  • core18
  • core20

And select LXD for when any other base is used. The reason to not say core22 and newer is that base introduction is not linear (e.g.; core22 may not be the next add base Snapcraft adds support for).

Setting a default

For users that want to keep a consistent user experience on a given system, no matter the base used to run Snapcraft against the project, Snapcraft (the snap), will make use of snap’s configure command, such that a user can execute:

snap set snapcraft provider <multipass|LXD>

Notification

A one time warning must be displayed when using bases that default to Multipass mentioning that the default will change when migrating to a newer base, with a notification about how to keep the current default before this comes into effect on Linux systems:

LXD will be the default environment for projects when changing base in snapcraft.yaml from core,
core18 and core20. Run `snap set snapcraft provider multipass` to keep the current default.
1 Like
2

Multipass.

Perhaps: Snapcraft will continue to use Multipass as the default when the base (or build-base) is: ...

Overall, I think it’d be a lot simpler to just state that this default will change with [build-]base core22. I am finding the the current phrasing a little odd to follow.

For example:

LXD is now the default environment for core22.  Run `snap set...`

As far as the notification, I think it might be better to consider a more comprehensive migration strategy/guide rather than one-off warnings imo. Will we be warning about the other changes as well in a similar fashion?

For example, when Snapcraft detects a project changing base to core22, it can provide a list of changes that appear to be applicable to the project in question:

The following behaviors have changed in core22:
- LXD is now the default environment.
  Consider running 'snap set snapcraft provider multipass' to maintain the previous behavior.
- Snapcraft will create/use the "snapcraft" LXD project...
  Consider running 'snap set snapcraft lxd-project default' or '--lxd-project default' parameter to maintain the previous behavior.
- The foo plugin's 'foo-property' default has changed to false.
  Consider specifying 'foo-property: true' to maintain the previous behavior.
- ...

Just a thought. :smiley:

:+1:

3

While generally the case, core22 is not the only new base we can add support for.

4

Indeed, we have a system for this, the deprecation notices.

5

“Multipass”

“can then select”?

I like the simplicity of this rule: “LXD will be the default from core22 and newer”

If I have my project using Multipass default, and I want to use LXD, why would I “change the default”? I just can go and use --use-lxd and I will start using LXD.

My point is that “changing the default” brings complexity, but which is the benefit? Having the following rules should be enough:

  • default Multipass if < core22
  • default LXD if >= core22
  • use --set-multipass/--set-lxd if want different than default
6

I clarified this in the text (why it is not possible, even if practical).

I clarified this, it would be to future proof behavior no matter the base used. If my project was using base: core20 if I ran Snapcraft on it, it would create a Multipass environment. when migrating I change the same project to base: core22, it would then all of the sudden create a LXD environment and I may not want that.

7

The overall idea looks sane to me, just raising a few wording issues:

This sentence is a bit confusing. Maybe rephrase to something like “Snapcraft today defaults to Multipass when running on native hardware in order to provide…”?

I think it’s enough to say that it should keep Multipass as the default for all existing projects. Also – if using the terminology listed in RFC 2119 – this may sound like a recommendation (meaning that in some cases the default is allowed to change), so perhaps “must keep Multipass as the default” could be less ambiguous here.

1 Like
8

It would also be interesting to mention how to handle the cases where lxd should not be set as the default, such as in Linux distributions that don’t fully support it, to avoid ending up with a default setting that doesn’t work.

9

Done

How will the migration be detected? Will old Multipass VMs for the prior base be cleaned automatically?