Hi @sed-i, thank you for the suggestion. This is a really interesting problem. In general, returning all the errors with a command is a really difficult thing to do: recognising some errors requires an "understanding" of underlying constructs, but that is only possible if there were no earlier errors when parsing/interpreting/assembling those constructs. That's also why compilers only report certain errors after earlier phases passed.

A practical example: in multipass launch -cpus 0, it would be very hard to say that 0 is below the minimum number of cpus, because 0 is actually being passed as the free <image> argument. Because of the single dash, the value specified for the number of CPUs is actually pus.

OK, but perhaps we could make a best effort to report as many errors as we can with the info we got? We could try, but that would still require a lot of work if we were to do it on a generic basis (diverting attention from other possible enhancements). Moreover, how far should we go? In the example above, should we contact the daemon to let it contact remotes to see if we can launch with image 0, when we already know we'll never be able to launch with pus cores?

So you see, I would rather bail as soon as we can. It certainly simplifies things a lot. However, having discussed with @townsend2010, I do recognise that wasn't the best user experience you had there. But I guess the main reason is that it is difficult to know what those minima are. A compromise in this particular case would be to print all of them when any value is found to be below the minimum (but without pointing out remaining errors). Something like:

$ multipass launch docker --name load-test --cpus 1 --memory 2G --disk 10GiB --mount /Users/me/code:/home/ubuntu/code
launch failed:
Requested Number of CPUs is less than Blueprint minimum. 
The docker blueprint requires at least 2 CPUs, 4GiB of memory, and 40GiB of disk space.

How does that sound? Do you think that would have been helpful?

Thanks @ricab. I think your proposal fully addresses the enhancement proposal.

We are going to change how blueprints handle this. Instead of being a hard fast minimum, it will instead be a default that can be overridden by the user at launch. If the user passes in resources that are less than the default, then we''ll coalesce any warnings that the user chose something under the minimum. See #3248.