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):
Steps to Reproduce:
1. Have a hypervisor with 0 socket submitted via yupana
Tally breaks and account is not tallied.
PFA to see the trace and log
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.
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.