Horizon current 2M huge page value set appears to be larger than the context help 2M Max value returned from horizon (vm_hugepages_possible_2M)

[Wendy Mitchell]

Horizon current 2M huge page value set appears to be larger than the context help 2M Max value returned from horizon (vm_hugepages_possible_2M)

Steps to Reproduce
------------------

1. On a newly installed system where no instances exist, log into Horizon and lock the compute host
eg. compute-1

2. Navigate to the Memory tab and click Update Memory to open the dialog.
Hover over the context help for eg. node 0 # of VM 2M Hugepages Node 0

3. Compare the value returned with the output (per node) for vm_hp_total_2M (and vm_hp_avail_2M) from system host-memory-list with the 2M values nova hypervisor-show <hostid> 'memory_mb_node'

!Note the current 2M huge page value set appears to be larger than the context help value returned from horizon in step 2.

My understanding is that the context value is vm_hugepages_possible_2M (which I understand is calculated on the node by sysinv agent as the total mem minus a base value)

4. In the Update Memory Allocation dialog, attempt to modify the 2M huge page value to something beyond the current and beyond the max for that node eg.to 29999.

Save

For eg. 2M memory current setting for node-0 is 27420
Max 2M memory setting according to Horizon is 27375 (why smaller)
attempt to set node-0 2M memory beyond max eg. try 27999

Error: Processor 0:No available space for 2M huge page allocation, max 2M pages: 27375

Expected Behavior
------------------
Consistency. The maximum setting value should match between context help Maximum 2M pages, error message maximum reported and that maximum which is allowed to be set

Actual Behavior
----------------
Result:
The Max 2M memory returned (vm_hugepages_possible_2M) in the error message matches Horizon context help but how is this smaller than current 2M memory_mb_node setting?

Reproducibility
---------------
reproduced (Horizon)

System Configuration
--------------------
Std 2 controller + X computes

Branch/Pull Time/Commit
-----------------------
master as of 2018-09-19_21-38-00

Branch/Pull Time/Commit
-----------------------

Timestamp/Logs
--------------

[Ghada Khalil (gkhalil)]

Targeting stx.2019.03 as this appears to be a minor issue

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/607326

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/607326
Committed: https://git.openstack.org/cgit/openstack/stx-config/commit/?id=121c76760e240bf15119dba0f8fd862e036441fc
Submitter: Zuul
Branch: master

commit 121c76760e240bf15119dba0f8fd862e036441fc
Author: Tao Liu <email address hidden>
Date: Tue Oct 2 11:31:45 2018 -0400

    2M hugepage appears to be larger than the context help

    On a newly installed system, the 2M huge page value is set by
    calculating 100% remaining available memory on the initial boot.
    The remaining memory in subsequent boot could be less than the
    initial boot, therefore the recalculated 2M Max value (shown in the
    context help) can be less than the previous set 2M huge pages.

    This update calculates the initial 2M huge page value using 90%
    remaining memory during the initial boot. In addition, it adds a
    notification to force sysinv-agent report memory when a host
    is locked. This prevents the audit delay causes the memory info not
    updated on time when the user attempts to modify the memory. The
    subsequent audit report is ignored when the host is locked. In this
    way host memory modify and host unlock semantic check use
    the same memory info as each audit could provide slightly different
    available memory value (depending on the activities performed on
    the system).

    Closes-Bug: # 1794547

    Change-Id: If3884946365254fc6be16f24df03dbd090454a76
    Signed-off-by: Tao Liu <email address hidden>