The apparmor profile would definitely need to be fixed if it's blocking the mkfs operations. However, in terms of the default format, there seems to be a following logic[1].
If mkfs_command nor explicit fs is specified, then default_ephemeral_format (None in the upstream, ext4 in the charm[2]). If default_ephemeral_format doesn't have a value, then the code looks for os_type and set the default fs as windows=ntfs, linux=ext4, and if there is no os_type specified, it falls back to vfat.
default_ephemeral_format=ext4 in the charm default might be too opinionated since the following fallback logic per OS in the upstream is always skipped.
The apparmor profile would definitely need to be fixed if it's blocking the mkfs operations. However, in terms of the default format, there seems to be a following logic[1].
If mkfs_command nor explicit fs is specified, then default_ ephemeral_ format (None in the upstream, ext4 in the charm[2]). If default_ ephemeral_ format doesn't have a value, then the code looks for os_type and set the default fs as windows=ntfs, linux=ext4, and if there is no os_type specified, it falls back to vfat.
default_ ephemeral_ format= ext4 in the charm default might be too opinionated since the following fallback logic per OS in the upstream is always skipped.
_DEFAULT_ FS_BY_OSTYPE = {'linux': FS_FORMAT_EXT4,
'windows' : FS_FORMAT_NTFS}
[1] https:/ /github. com/openstack/ nova/blob/ stable/ ussuri/ nova/privsep/ fs.py#L290- L305 /bugs.launchpad .net/charm- nova-compute/ +bug/1693943
[2] https:/