release: Build UFS and ZFS VM images

[cperciva]

Summary

A new option 'VMFSLIST' controls the list of filesystems for which VM
images will be built; the default is to build both UFS and ZFS.

The vm-install target installs these as ${OSRELEASE}-${FS}.${FORMAT},
e.g. FreeBSD-14.0-CURRENT-amd64-zfs.vmdk. For backwards compatibility,
the ${VMFS} image is linked to the previously used ${OSRELEASE}.${FORMAT}
name.

Cloudware building will be updated in a later commit.

Sponsored by: https://www.patreon.com/cperciva

[emaste]

release/Makefile.vm

11–12

Should we just get rid of VMFS (perhaps after a short period)? Or is the intent that we'll want to continue offering an image name that does not specify the fs type (and could perhaps switch from UFS to ZFS in the future)?

[cperciva]

release/Makefile.vm

11–12

Yes, in the long term we should probably get rid of VMFS. I was leaving it there for backwards-compatibility purposes in case people have scripts which grab e.g. FreeBSD-14.0-CURRENT-amd64.vhd from ftp-master. It's also used as a default filesystem for the ec2ami target (for people who want to build a single AMI) but that could change to an EC2_FS_DEFAULT option or something like that.

[markj]

This diff should update release.7.

release/Makefile.vm

11–12

VMFS is only present in main, so I don't know that there's that much of a backward compatibility concern?

Alternately, just extend the meaning of VMFS, so that setting VMFS=zfs will do what it did before, and VMFS=ufs zfs now does what you want VMFSLIST=ufs zfs to do. Though, that becomes a bit confusing if you only embed the FS name when multiple filesystems are specified. So on second thought, the separate VMFSLIST variable seems better.

181

.if defined(WITH_COMPRESSED_VMIMAGES) && !empty(WITH_COMPRESSED_VMIMAGES)
COMPSUFF=.xz
.endif

.for FORMAT in ${VMFORMATS}
    ln -f ${DESTDIR}/vmimages/${OSRELEASE}-${VMFS}.${FORMAT}{COMPSUFF} ${DESTDIR}/vmimages/${OSRELEASE}.${FORMAT}${COMPSUFF}
.endfor

just to avoid some of this duplication.

[gjb]

Note, parts of release/Makefile.mirrors will need to change as well, notably in 'vm-stage-images'. I will take a look at this during the week. Though, I think your compatibility symlinks resolves the immediate thing regarding the 'ftp-stage' target I am thinking of.

[cperciva]

Update release.7.

[cperciva]

Note, parts of release/Makefile.mirrors will need to change as well, notably in 'vm-stage-images'. I will take a look at this during the week. Though, I think your compatibility symlinks resolves the immediate thing regarding the 'ftp-stage' target I am thinking of.

Note: Hard links, not symlinks. Yes, I wasn't sure what to do with Makefile.mirrors but I hoped that the compatibility links would result in things continuing to work (with the single UFS image) for now.

release/Makefile.vm

181

@markj Are you ok with me leaving this as it is for now? In the long term we're going to be getting rid of the compatibility links anyway.

[emaste]

release/Makefile.vm

175–181

can we just move this inside the existing . if defined(WITH_COMPRESSED_VMIMAGES) && !empty(WITH_COMPRESSED_VMIMAGES) block?

[markj]

release/Makefile.vm

181

I'm ok with leaving it as it is.

I don't quite understand Ed's suggestion: we have a loop for both the compressed and uncompressed cases.

[cperciva]

Fix missing filesystem loop around xz command.

[cperciva]

release/Makefile.vm

175–181

Not really; the ln -f for compressed images could be merged but we would still need an "else for FORMAT in $VMFORMATS" so I think it would be even more confusing.

The if/for logic could be deduplicated a bit here, but not completely.

[gjb]

In D41340#942620, @cperciva wrote:

Note, parts of release/Makefile.mirrors will need to change as well, notably in 'vm-stage-images'. I will take a look at this during the week. Though, I think your compatibility symlinks resolves the immediate thing regarding the 'ftp-stage' target I am thinking of.

Note: Hard links, not symlinks. Yes, I wasn't sure what to do with Makefile.mirrors but I hoped that the compatibility links would result in things continuing to work (with the single UFS image) for now.

Right. Thank you for the correction. That is indeed what I meant.