Description of problem: There are two means to bring hypervisor hosts to HBI in Subwatch , 1. Yupana (Satellite) 2. RHSM-Conduit (RHSM) If any Hypervisor with 0 socket counts makes it way to HBI, the next tally onwards on the account fails Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Have a hypervisor with 0 socket submitted via yupana 2. 3. Actual results: Tally breaks and account is not tallied. PFA to see the trace and log Expected results: There should be validation happening to detect the 0 hypervisor socket and stop it from being submitted to HBI. Currently, there is validation at rhsm-conduit, there should be the same in yupana aswell. Additional info: This only affects the hypervisors submitted via Yupana, i.e Red hat Cloud Satellite Plugin.
This has been addressed in rhsm-subscriptions such that a tally run will not fail when a host is processed in this state. The end result is that Tally will record the host with 0 sockets (for discovery if need be) but the API should filter then as it has already been doing. As far as I know, the hypervisor host is not currently being validated in Yupana as suggested by the reporter to prevent the host from reaching HBI (as rhsm-conduit is doing). I'm going to leave this bug open until this has been addressed.
The 0 socket count issue is being addressed in foreman-rhcloud as well. To ensure sanity of data, we should filter these in Yupana as well. Do we have a spec on which system facts similar to `cpu::cpu_socket(s)` should be inspected and dropped?
Do we have a bugzilla for foreman-rhcloud ? If not I think we should create as it would be a two part fix and easier to cherrypick in other versions of the plugin , Can we add it to see also in here, for better tracking.
Fix in Tally was pushed to production.