Bug 2049828

Summary: Config Reports show future-dated times and error "Host times seem to be adrift" for Ansible jobs only
Product: Red Hat Satellite Reporter: Jessica Richards <jrichards2>
Component: Ansible - Configuration ManagementAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DUPLICATE QA Contact: Sam Bible <sbible>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.10.1CC: oezr, wpinheir
Target Milestone: UnspecifiedKeywords: Regression, Triaged, UserExperience
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-02-03 18:18:43 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 Flags
screenshot of monitor > config management showing future-dated times none

Description Jessica Richards 2022-02-02 18:45:31 UTC
Description of problem:

When customers use Satellite 6.10 to run all Ansible roles against their hosts, the results (whether failures or successes) appear under Monitor > "Config Management" with future-dated times.  Moreover, when they click on any of the results, they see errors like this:

Host times seem to be adrift!
Host reported time is 2022-02-02 01:46:32 -0700
Satellite report creation time is 2022-02-01 18:46:32 -0700
Which is an offset of about 7 hours

However, the customer's hosts don't show this clock drift.  We also compared time zone differences, and they didn't match the reported offsets, either.

I was able to reproduce this issue on my own Satellite 6.10 server as well, using both the customer's Ansible roles and Red Hat's Ansible roles (specifically, RedHatInsights.insights-client).

However, when altering the search criteria to look for the Satellite server, we can see updates from puppet that don't have this problem.


Version-Release number of selected component (if applicable):

satellite-6.10.1-2.el7sat.noarch
ansible-test-2.9.27-1.el7ae.noarch
ansible-runner-1.4.6-1.el7ar.noarch
ansible-collection-redhat-satellite-2.2.0-1.el7sat.noarch
ansible-2.9.27-1.el7ae.noarch

satellite-6.10.2-1.el7sat.noarch
ansible-test-2.9.27-1.el7ae.noarch
ansible-runner-1.4.6-1.el7ar.noarch
ansible-collection-redhat-satellite-2.2.0-1.el7sat.noarch
ansible-2.9.27-1.el7ae.noarch


How reproducible:

100%


Steps to Reproduce:
1.  assign one or more ansible roles to a host
2.  go to Hosts > All Hosts
3.  run all ansible roles against a host

Actual results:

- result shows up under Monitor > "Config Management" with a future time
- the result details themselves report clock drift


Expected results:

- result should show up under Monitor > "Config Management" with a past but recent time
- the result details themselves shouldn't erroneously report clock drift

Comment 1 Jessica Richards 2022-02-02 18:50:16 UTC
Created attachment 1858745 [details]
screenshot of monitor > config management showing future-dated times

Comment 3 Jessica Richards 2022-02-02 19:01:06 UTC
note:  the customer's servers had different timezones defined.  their timezones were three hours apart, whereas their error message showed a 5 hour "drift".  however, when i reproduced the issue in my environment, my servers were in the same timezone, and the satellite/ansible-reported drift was even greater.

also note:  i was unable to reproduce this problem in satellite 6.9.

Comment 4 Ondřej Ezr 2022-02-03 18:18:43 UTC
Hi, this is most likely a duplicate of bz#2035907 that is aligned to 6.10.z so the fix should get to a 6.10 z stream soon.

*** This bug has been marked as a duplicate of bug 2035907 ***