sysinv-conductor can lose pending hugepage count data

[Don Penney]

Brief Description
-----------------
A race condition exists during initial AIO configuration where sysinv-conductor can lose the hugepage _pending counts, between the initial sysinv configuration and the allocation of hugepages after the initial unlock. A query during this window can result in a nil pending value with pagecount of 0 (where the pagecount is actual configured hugepages), when a non-zero count has been requested, rather than continuing to show a non-zero pending value until the memory allocation is complete.

Severity
--------
Minor

Steps to Reproduce
------------------
On an AIO-SX system, configure a non-zero hugepage count. Post-unlock, query the system memory data in the window between sysinv-conductor launching, memory allocation is performed via worker puppet manifest, and the sysinv-agent audit updating sysinv-conductor with the newly configured hugepages.

Expected Behavior
------------------
sysinv-conductor should continue to report a non-zero pending value until its hugepage count is updated.

Actual Behavior
----------------
sysinv-conductor wipes the pending value upon update from sysinv-agent, when the admin state is unlocked. The sysinv-agent audit can result in this update being sent multiple times prior to hugepage allocation.

Reproducibility
---------------
Intermittent

System Configuration
--------------------
AIO

Branch/Pull Time/Commit
-----------------------
master branch, June 2, 2020

Last Pass
---------
n/a

Test Activity
-------------
Sanity

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/733523
Committed: https://git.openstack.org/cgit/starlingx/config/commit/?id=70f4967b435a9577226022b183f921c007af1acd
Submitter: Zuul
Branch: master

commit 70f4967b435a9577226022b183f921c007af1acd
Author: Don Penney <email address hidden>
Date: Thu Jun 4 05:06:25 2020 -0400

    Fix sysinv hugepage pending value handling in memory updates

    A race condition exists during initial AIO configuration where
    sysinv-conductor can lose the hugepage _pending counts, between the
    initial sysinv configuration and the allocation of hugepages after the
    initial unlock. A query during this window can result in a nil pending
    value with pagecount of 0 (where the pagecount is actual configured
    hugepages), when a non-zero count has been requested, rather than
    continuing to show a non-zero pending value until the memory
    allocation is complete.

    This commit updates the imemory_update_by_ihost function to check
    whether the pending value aligns with the configured hugepage count,
    prior to clearing it.

    Change-Id: I94fee45be2c3bdb2b7b80f9badcec4ff3f6fbbf8
    Closes-bug: 1882044
    Signed-off-by: Don Penney <email address hidden>