multipass shouldn't refuse to launch unsupported images

[OddBloke]

In #734, we ran in to problems launching trusty VMs because streams had (incorrectly) started reporting trusty as unsupported.

A reasonable use of VMs is to isolate applications that rely on unsupported releases of Ubuntu; I've had to do this a couple of times for abandonware that I needed to use temporarily. With the current multipass behaviour, I wouldn't be able to do that.

I think it would be preferable for multipass to allow me to bypass this check somehow, to enable this use case.

[OddBloke]

My two thoughts for implementation were: (a) simply report a warning about the image's support status during launch, or (b) provide a CLI flag that skips the check (--yes-i-acknowledge-that-this-is-probably-a-decision-i-will-regret)

[townsend2010]

@OddBloke,

Is the http method you referred to or manually downloading the file and use 'file:///path/to/image not good enough?

I think from a UI perspective, only supported aliases should be used and I feel the aforementioned methods are a good workaround.

[OddBloke]

I have a few thoughts in response:

• cloud-images.ubuntu.com doesn't remove images and continues to publish streams for unsupported releases specifically to allow this type of post-EOL use case/workflow. It makes sense to me that our Ubuntu launcher should also allow it (with appropriate guard rails, of course, as discussed above).

• In a couple of weeks, multipass will support launching unsupported aliases anyway; trusty will only receive security updates if people attach their launched VMs to UA and enable ESM.

• I think there's a class of user who will think "oh, let me try multipass for the VM I run for this crappy old Java app" and when multipass launch precise craps out on them will just discount multipass entirely; those "I only run one pet VM" people should be right in multipass's wheelhouse, IMO.