image.yaml: Support split /var

[cgwalters]

We should at least support something like:

rootfs: 3

And have the rest default to /var.

[jlebon]

Related: https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#disk-layout
And discussions that happened in: coreos/fedora-coreos-tracker#18

I guess eventually the end goal is to be able to describe such a layout in image.yaml?

[ajeddeloh]

So I have thoughts on this. A somewhat silly, but possible route is to use Ignition disks in a supermin-like vm (we'd need systemd in it) and specify the disk via an Ignition config. This does mean that the format is somewhat fixed, however. This does however have the advantages of already existing and defining the disk layout in a declarative way. Switching supermin to use systemd might be an adventure, however.

CL uses a tool called disk_util which takes in a json file and creates partitions/filesystems. I don't have any strong attachment to it. I'd rather something simpler.

[cgwalters]

Switching supermin to use systemd might be an adventure, however.

Ultimately...it feels like there's no reason we can't bootstrap something that feels more "FCOS like" in supermin (things get recursive fast I know, but the "proto FCOS" here would just be hardcoded to ext2 or whatever as supermin does today).

Are you thinking we'd use a YAML transpilation of the Ignition storage section? Or JSON?

[ajeddeloh]

Ultimately...it feels like there's no reason we can't bootstrap something that feels more "FCOS like" in supermin (things get recursive fast I know, but the "proto FCOS" here would just be hardcoded to ext2 or whatever as supermin does today).

This gets at a more core set of questions: Do we have multiple minimal supermin appliances or one big one? Not really sure which route we want to go down. If it's the first then we ought to figure out how to shove systemd inside supermin, if its the latter, then proto-fcos makes more sense.

Ultimately (and wayyyy down the road) I'd like to no have to use supermin at all and run unprivileged using user namespaces to solve our problems. For image creation we could do something like create files for partitions, run mkfs on those files and the mount the files instead of block devices. We're actually pretty close to this today; sgdisk, mkfs, etc are all happy to run on regular files. The biggest roadblock I hit while experimenting with this is that we can't mount them without root. At the end of all this we'd "inject" the filesystem images inside the disk image at the correct offsets into the disk image file. I also don't know how much of a fight grub would put up running on a regular file, but that's workable too.

I'm not sure how close we are for the oscontainer stuff since I haven't been tracking that closely.

Are you thinking we'd use a YAML transpilation of the Ignition storage section? Or JSON?

Either? Its all automated so doesn't much matter. Might be useful to render it to json explicitly since other tools can then read it with jq if we wanted to embed bits of it in metadata or something

[dustymabe]

We don't currently ship with a separate /var/ partition by default and we don't have any plans to change. On firstboot a /var/ partition can be added via Ignition configuration.