Consistent units in status.recommendation when displaying memory as "raw bytes"

[akrzos]

Which component are you using?:

/area vertical-pod-autoscaler

What version of the component are you using?:

vertical-pod-autoscaler.v4.19.0-202507171007

What k8s version are you using (kubectl version)?:

# kubectl version
Client Version: v1.32.1
Kustomize Version: v5.5.0
Server Version: v1.32.5

What environment is this in?:

libvirt virtual machines

What did you expect to happen?:

I expect recommendations to be provided in consistent units when --humanize-memory=false. I also expect units to be consistent either SI or IEC when --human-memory=true

What happened instead?:

Without setting --humanize-memory in the status field for a VPA CR I see:

    recommendation:
      containerRecommendations:
      - containerName: stress
        lowerBound:
          cpu: 25m
          memory: 262144k
        target:
          cpu: 25m
          memory: 262144k
        uncappedTarget:
          cpu: 25m
          memory: 262144k
        upperBound:
          cpu: 13987m
          memory: "14623264705"

For target.memory the value 262144k means 262144000 bytes, why not just show 262144000 instead of appending a unit to the value?

When I have set --humanize-memory on the recommender I observed:

    containerRecommendations:
    - containerName: stress
      lowerBound:
        cpu: 25m
        memory: 250Mi
      target:
        cpu: 25m
        memory: 250Mi
      uncappedTarget:
        cpu: 25m
        memory: 250Mi
      upperBound:
        cpu: 5291m
        memory: 5529770393600m

Now it seems most memory recommendations used a binary unit however upperBound still did not.

How to reproduce it (as minimally and precisely as possible):

Create a VPA and observe the status.recommendation field units

Anything else we need to know?:

I would expect without --humanize-memory that the displayed memory would always be in a "unitless" display of just bytes.

[adrianmoisey]

Is this a dupe of #7770 ?

[akrzos]

Is this a dupe of #7770 ?

I believe there is some overlap but not entirely, without --humanize-memory I am seeing units attached to the recommendation that means you need to "convert" it to raw bytes anyway. I don't think we should expect that.

[adrianmoisey]

I believe there is some overlap but not entirely, without --humanize-memory I am seeing units attached to the recommendation that means you need to "convert" it to raw bytes anyway. I don't think we should expect that.

Right, gotcha

vertical-pod-autoscaler.v4.19.0-202507171007

Which version of VPA is this? We don't have a 4.19 version available

[adrianmoisey]

I believe that #8298 may help out here

[akrzos]

I believe there is some overlap but not entirely, without --humanize-memory I am seeing units attached to the recommendation that means you need to "convert" it to raw bytes anyway. I don't think we should expect that.

Right, gotcha

vertical-pod-autoscaler.v4.19.0-202507171007

Which version of VPA is this? We don't have a 4.19 version available

v1.2.0

[omerap12]

With #8298 merged we should deprecate the humanize-memory flag.
Please use round-memory-bytes flag instead.

[akrzos]

With #8298 merged we should deprecate the humanize-memory flag. Please use round-memory-bytes flag instead.

I don't think this will solve the issue of "raw bytes" having various units attached to the metric. Even if it rounds the "Raw bytes" to a "nicer" number (Ex 128Mi or 256Mi) the number still has a unit attached and could be interpreted as a string instead of an integer.