Very helpful, thanks @vorlon. This clears some (most?) of our confusion.
Apologies for invading a netbooting discussion with a (slightly?) off-topic point. (It’s the only place I could quickly find on why mini.iso
is not working.)
[disclaimer: the following note is possibly longer/wordier than need be. We prioritized speed-of-reply over conciseness.]
The current cloud-init server (20.04) .img
is ~7-times larger than the mini.iso
and equates to roughly 450MB of additional space of per-kvm footprint, which can be a big deal in large-scale deployments (and why things like Alpine matter, from what we can tell) that are fully-cloning the images; think qtys=1,000 to 100,000, in each of potential multiple geograhic (datacenter) deployments. But to note: the aforementioned is “dumb” math that does not account for “real” storage/bandwidth use in fully-built kvms, containers. So, we’ll see. And maybe we will not want a kvm-based solution for that and rather strictly container-ish based, which (potentially) dramatically reduces the resource load.
I totally get where Ubuntu is coming from on not wanting to support small-image stuff, that makes a boatload of sense. We would not either, if there’s not a good use-case and sufficient demand that matters to the project and the business.
If and when we want a “stripped down” image for larger-scale deployments, and we want it to be Ubuntu-based, we’ll have to strip it down ourselves (or go with a non-Ubuntu alternative like Alpine, Debian, or something else which will have other issues) if we care about resources in larger-scale deployments (which… maybe we will not after run our prototype testing in each context/application/domain?). Lots of extra work. And no support from Ubuntu.
I suspect Canonical has run the analysis and decided: there isn’t much demand for the above. (eg, again: “when running lots of kvm’s, run containers instead, and then there’s less impact from larger-image size.”)
Separately: maybe there’s another, Ubuntu-based alternative that we do not know that can help us address potential contexts like the above? (We where lots of hats in our realm, and we’re far from OS-deployment experts; we’d love to learn that we’ve overlooked a better solution/approach.)