Humanize byte counts in event messages (e.g. image pull size)

[TomerKarniol]

Problem

In the events view, the kubelet's "Pulled" event message ends with the image size as a raw byte count:

Successfully pulled image "quay.io/kubevirt/virt-controller:v1.9.0" in 11.851s (11.851s including waiting). Image size: 80474558 bytes.

At a glance, 80474558 bytes is hard to read. You have to count digits to see it is about 77 MB. Sofka already shows memory and similar values in human units elsewhere, but event messages are printed exactly as the cluster sends them.

How I handle it now

I count digits by eye or copy the number into a calculator. Both are slow when scanning events for a slow or oversized pull.

Proposal

When rendering an event message, rewrite <N> bytes into an auto-scaled binary unit. The example above would show Image size: 76.7 MiB.

• The unit is chosen per value: KiB, MiB or GiB. A fixed unit would turn small images into 0.07 GiB, so the scale has to follow the value.
• Only the display changes. The raw message stays available when the event is copied or viewed in full.
• It applies only to the pattern <digits> bytes. Other text in the message is left alone.

Open questions for maintainers

1. Should the rewrite apply to every event message, or only to Pulled events?
2. Should it be configurable, or always on?
3. Is it fine to alter cluster-provided message text in the table, as long as the raw text is still reachable?

Scope

I'm happy to implement this once the scope is agreed. It would be a small change in the event message column, with a handle_key test and a docs/features.md update.

[nklmilojevic]

done in latest release