Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1702228 - Display memory in consistent way
Summary: Display memory in consistent way
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Compute Resources - CNV
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: 6.6.0
Assignee: Moti Asayag
QA Contact: Lukáš Hellebrandt
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-23 09:22 UTC by Shira Maximov
Modified: 2019-10-22 19:51 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-22 19:51:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 26656 0 None None None 2019-04-23 09:23:26 UTC

Description Shira Maximov 2019-04-23 09:22:10 UTC 
Based on the feedback from the mailing list:


<pre>
Can you explain why one VM showed 1024Mi where others showed 1Gi for the memory?
It looked like it came straight from the API since the console also showed 1Gi where Foreman normally uses GB.
</pre>

We need to make sure to always use GB while displaying virtual machine memory.
---
There is inconsistency in the reported memory - we should normalize it to a single units:
<pre><code class="ruby">

2.3.3 :016 > c.servers.map { |s| s.memory }
=> ["1Gi", "1024Mi", "1024Mi", "1024M"]

</code></pre>

So we got Gi, Mi and M - but that doesn't contradict:
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory

However, can fractions be specified ? Assuming user would like less than 1G vm ?
We faced similar issue with MIQ kubevirt provider here:
https://github.com/ManageIQ/manageiq-providers-kubevirt/blob/master/app/models/manageiq/providers/kubevirt/memory_calculator.rb#L31
Comment 3 Shira Maximov 2019-04-23 09:23:28 UTC 
Created from redmine issue https://projects.theforeman.org/issues/26656
Comment 4 Shira Maximov 2019-04-23 09:23:30 UTC 
Upstream bug assigned to mshira
Comment 5 Bryan Kearney 2019-05-02 10:01:17 UTC 
Upstream bug assigned to mshira
Comment 9 Lukáš Hellebrandt 2019-07-18 13:30:57 UTC 
This fix changed memory units so that there is now inconsistent use of prefixes: KB, MB, GB now mean:
1) 10^3, 10^6, 10^9 in Kubevirt
2) 2^10, 2^20, 2^30 in Satellite
The result is that if you create a 1024M VM in Kubevirt, it is shown as 977 MB VM in the Satellite.

This doesn't seem like a bug, more like a inconsistency between those projects. Meaning of the units is documented. It can, however, confuse a user and doesn't look good at all.

Because I can't propose any better solution, I'm ready to verify this BZ once Moti confirms this is intended.
Comment 10 Moti Asayag 2019-07-22 05:27:12 UTC 
(In reply to Lukáš Hellebrandt from comment #9)
> This fix changed memory units so that there is now inconsistent use of
> prefixes: KB, MB, GB now mean:
> 1) 10^3, 10^6, 10^9 in Kubevirt
> 2) 2^10, 2^20, 2^30 in Satellite
> The result is that if you create a 1024M VM in Kubevirt, it is shown as 977
> MB VM in the Satellite.
> 
> This doesn't seem like a bug, more like a inconsistency between those
> projects. Meaning of the units is documented. It can, however, confuse a
> user and doesn't look good at all.
> 
> Because I can't propose any better solution, I'm ready to verify this BZ
> once Moti confirms this is intended.


In kubernetes there are 2 sets of units: KB/MB/GB and KiB/MiB/GiB
Therefore if you create a VM on KubeVirt side with 1GiB, you'll see it as 1GB on satellite side.
If you create a VM with 1024MB on KubeVirt side, you'll see it as 977MB on satellite side.

Satellite units relies on https://api.rubyonrails.org/classes/ActionView/Helpers/NumberHelper.html#method-i-number_to_human_size
When you create a VM on satellite side with 1GB, you'll see it as 1GiB on KubeVirt side.
The behavior was intended to satisfy memory size as provided from satellite side, so if user specified 1GB, the reported memory for the vm should be 1GB and not 977MB.
This is done by using the power of 2 scale when setting memory size on VM creation, and using the same scale to represent it on VMs view.
Comment 11 Lukáš Hellebrandt 2019-07-22 08:44:50 UTC 
Verified using Sat 6.6 snap 11.

Verifying based on comment 9, comment 10 and the fact that creating a 1G VM in Sat leads to VM that shows as 1g in Sat and 1Gi in Kubevirt.
Comment 12 Bryan Kearney 2019-10-22 19:51:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3172
Note You need to log in before you can comment on or make changes to this bug.