AdamWill
commented
5 months ago Couple of notes:
- the typing here is weird, but I've left it as-is.
_parse_disksizereturns a string, before and after this patch. But thegenerate_diskimagemethods and_internal_generate_diskimageimplicitly expect ints, since the default value for each is an int. In the end,_internal_generate_diskimagedoesstr(int(capacity))(wherecapacityis justsizein this case), which forcibly gets rid of the ambiguity I guess, but it seems a bit inelegant. - AFAICT,
test-60-command-mix-positions-and-not.tdl,test-61-command-duplicate-position.tdlandtest-62-repository-localhost.tdlare not currently run and have never been run. I left this as-is too, but it might want fixing.
keszybz
Currently, oz only allows image sizes to be specified as integer amounts of gibibytes or tebibytes (that's IEC power-of-two units). This is unfortunately inflexible. Consider that storage media are typically specified in SI power-of-ten sizes, so a USB stick may be 16 gigabytes (SI power-of-ten GB) in size - that's 16,000,000,000 bytes. Let's say we want to build an image that will fit on such a USB stick. oz will only allow us to build an image of 15,032,385,536 bytes (14 gibibytes) or 16,106,127,360 bytes (15 gibibytes). So we're either slightly too big, or leaving nearly a gigabyte on the table.
This allows the image size to be specified in the TDL with most any IEC or SI unit suffix, from B (bytes) all the way up to YiB (yobibytes). A size with no suffix or the suffix "G" is taken as gibibytes and a size with the suffix "T" is taken as tebibytes, as before, but other ambiguous suffixes are not accepted. All casing is accepted. Behind the scenes, we convert the size to bytes and specify it that way in the libvirt XML when creating the image in _internal_generate_diskimage.
This does change the interface of generate_diskimage(), by making the unit for the size argument bytes instead of gibibytes. I can't see a clean way to avoid this while allowing flexibility. I have checked, and AFAICT, among active projects, only oz itself and the ImageFactory TinMan plugin call this function. The TinMan plugin will need a trivial change to its fallback default value.
This is currently tagged WIP because I am not sure it's safe to include the sizeof_fmt snippet; its licensing is complicated. I'm asking Richard Fontana for his wisdom on this ATM. If it's not safe to include we'll have to rewrite it or just print the size in bytes or something.