Bug 1823396
| Summary: | Hosts are rejected due to mismatch of metadata.json and actual hosts included in satellite inventory report | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Parag Kamble <pakamble> | ||||
| Component: | RH Cloud - Inventory | Assignee: | Shimon Shtein <sshtein> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Mirek Długosz <mzalewsk> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.7.0 | CC: | egolov, jjeffers, kholdawa, pcreech, sjagtap, sshtein | ||||
| Target Milestone: | 6.7.4 | Keywords: | Reopened, Triaged | ||||
| Target Release: | Unused | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | tfm-rubygem-foreman_rh_cloud-1.0.6 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-09-30 13:12:09 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Parag Kamble
2020-04-13 14:56:37 UTC
*** This bug has been marked as a duplicate of bug 1812858 *** *** This bug has been marked as a duplicate of bug 1821335 *** *** This bug has been marked as a duplicate of bug 1812858 *** Also, this writeup confuses different layers. Ingress does not reject anything or validate anything. Possible issues include: 1. Yupana rejects tar.gz format because you did not conform to syntax (see https://github.com/quipucords/yupana#-formatting-data-for-yupana-without-qpc). However, this has nothing to do with subscription_status 2. HBI may reject a host (not the tar.gz) based on invalid syntax. Yupana does NOT validate hosts. HBI validates hosts. So likely HBI didn't like subscription_status I do not think these issues are the same. - Bug https://bugzilla.redhat.com/show_bug.cgi?id=1812858 relates to yupana validation - This bug relates to HBI validate - Ingress doesn't validate (so the title of this bug is confusing) Indeed, the problem is not about subscription_status. What happens here is the following sequence: Suppose we have a Satellite with only one host. When a report is created, it will contain only one host, and hosts count in metadata.json will also be 1 Now we add a host using subscription-manager register --org="Default_Organization" --environment="Testing/cv1" This host does not have valid pools associated with it. When a report is created, the amount of _potential_ hosts is reported - so metadata.json will contain a slice with count set to 2. While generating the slice, the plugin will skip generating a report for the new host, hence the report will still contain 1 host. If we upload this report, it will be rejected by yupana (hence the connection to 1812858). Now we re-register the host using subscription-manager register --org="Default_Organization" --activationkey="activation_key_1" --force When using such registration method, the host gets a pool associated to it Now when we generate the report, metadata.json will still contain count=2 potential hosts. The slice will contain 2 hosts as well, since both hosts have valid pools in them. This report will not be rejected by yupana, and the new host will appear in HBI. Originally the "Unentitled" status was suspected to have something to do with the fact the data did not appear in HBI. Sanket's tests actually reassured my findings from reading both Yupana's and HBI validation code that status value has nothing to do with this reject. Bottom line is that it is very hard to identify where the reject comes from - HBI or Yupana. Kevan, does this explanation make more sense to you? Changing the title to make it less confusing, but I still think this is a duplicate issue and can be tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1812858 Shim, I am not sure I follow the complication. The metadata should be simple to generate if you order it correctly. 1. Generate the slice files 2. Since the files are generated, create a metadata section that captures what was generated. The metadata is simply a summary of what you are sending. It should be easy to generate right before you create the tar.gz and it will be accurate at that point. 3. Create tar.gz with the metadata and slice json files @Kevan, this one was fixed in https://github.com/theforeman/foreman_rh_cloud/pull/160 So moving this bug to POST since the actual problem is already fixed since x.y.5 release. Only hosts with subscriptions are included in report, report metadata matches number of hosts in slice. Tested on: Satellite 6.8.0 snap 5 pulp-server-2.21.2-1.el7sat.noarch satellite-6.8.0-0.4.beta.el7sat.noarch foreman-2.1.0-0.20.rc2.el7sat.noarch katello-3.16.0-0.3.rc1.el7sat.noarch tfm-rubygem-foreman_rh_cloud-2.0.7-1.el7sat.noarch That was fixed in Satellite 6.7.2 with plugin version 1.0.9, but I gave it another round on 6.7.4. Same result - Only hosts with subscriptions are included in report, report metadata matches number of hosts in slice. Tested on: Satellite 6.7.4 snap 1 pulp-server-2.21.0.4-1.el7sat.noarch foreman-1.24.1.28-2.el7sat.noarch satellite-6.7.4-1.el7sat.noarch katello-3.14.0-6.el7sat.noarch tfm-rubygem-foreman_rh_cloud-1.0.10-1.el7sat.noarch 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 (Important: Satellite 6.7.4 Async Bug Fix Update), 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-2020:4127 |