Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem, and how to reproduce it:
With reference to https://bugzilla.redhat.com/show_bug.cgi?id=1999089#c10 :
The files virt-who-config-*.conf all report into the same Satellite organization (owner=Example_Org) but authenticate to Satellite as different users (rhsm_username=virt_who_reporter_2 , rhsm_username=virt_who_reporter_3, and so on), they generate separate connection requests to report on their generated host-to-guest mappings. This is when the customer experiences the issue with missing hypervisors in the mappings.
Changing 'rhsm_username' in all virt-who-config-*.conf files to 'rhsm_username=virt_who_reporter_2', and restarting the virt-who service, forced all virt-who-config-*.conf files to submit one single report, and the customer no longer encounters the issue.
Also observed that when each virt-who config is configured to use its own virt-who reporter, there are multiple Hypervisors tasks with very short (1 or 0 seconds) duration which although show as being successful in Satellite. But when you examine them in the dynflow console, they have actually failed:
For example:
~~~
Id: a4e6c9e0-9209-490c-bd59-799a65212f93
Label: Actions::Katello::Host::Hypervisors
Status: stopped
Result: success
Started at: 2021-12-05 14:14:39 UTC
Ended at: 2021-12-05 14:14:39 UTC
3: Actions::Candlepin::AsyncHypervisors (success) [ 0.10s / 0.10s ]
Queue: hosts_queue
Started at: 2021-12-05 14:14:39 UTC
Ended at: 2021-12-05 14:14:39 UTC
Real time: 0.10s
Execution time (excluding suspended state): 0.10s
Input:
---
task_id: 8a3188c67d8ae15d017d8af25d390035
session_id:
remote_user: admin
remote_cp_user: admin
current_request_id:
current_timezone: UTC
current_user_id: 17
current_organization_id:
current_location_id:
Output:
---
hypervisors: []
task:
created: '2021-12-05T14:14:39+0000'
updated: '2021-12-05T14:14:39+0000'
id: 8a3188c67d8ae15d017d8af25d390035
name: Hypervisor Update
group:
origin: satellite.example.com
executor:
principal: foreman_admin
state: FAILED <<<<<----- reporting 'FAILED' here ----->>>>>
previousState: CREATED
startTime:
endTime:
attempts: 0
maxAttempts: 1
statusPath: "/jobs/8a3188c67d8ae15d017d8af25d390035"
key: HypervisorUpdateJob
5: Actions::Katello::Host::HypervisorsUpdate (success) [ 0.08s / 0.08s ]
Queue: hosts_queue
Started at: 2021-12-05 14:14:39 UTC
Ended at: 2021-12-05 14:14:39 UTC
Real time: 0.08s
Execution time (excluding suspended state): 0.08s
Input:
---
hypervisors: []
remote_user: admin
remote_cp_user: admin
current_request_id:
current_timezone: UTC
current_user_id: 17
current_organization_id:
current_location_id:
Output:
---
results:
7: Actions::ForemanVirtWhoConfigure::Config::Report (success) [ 0.02s / 0.02s ]
Queue: default
Started at: 2021-12-05 14:14:39 UTC
Ended at: 2021-12-05 14:14:39 UTC
Real time: 0.02s
Execution time (excluding suspended state): 0.02s
Input:
---
hypervisors:
hypervisors: []
current_request_id:
current_timezone: UTC
current_user_id: 17
current_organization_id:
current_location_id:
Output:
--- {}
~~~
Actual results:
Multiple 'Actions::Katello::Host::Hypervisors' tasks with very short (1 or 0 seconds) duration which although show as being successful in Satellite. But when you examine them in the dynflow console, they have actually failed.
Expected results:
When a similar condition occurs, 'Actions::Katello::Host::Hypervisors' tasks which failed as per the dynflow console are also reported as failed in Satellite.