Bug 1613752 - [HtaFZbiR] ValueError: time data does not match format when executing network diagnostics ansible playbook
Summary: [HtaFZbiR] ValueError: time data does not match format when executing network...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.11.0
Assignee: Miciah Dashiel Butler Masters
QA Contact: zhaozhanqi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-08 09:48 UTC by Hongan Li
Modified: 2022-08-04 22:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-11 07:24:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github https://github.com/openshift openshift-ansible pull 9482 0 None None None 2018-08-08 15:51:41 UTC
Red Hat Product Errata RHBA-2018:2652 0 None None None 2018-10-11 07:24:26 UTC

Description Hongan Li 2018-08-08 09:48:30 UTC
Description of problem:
when executing the network diagnostics ansible check playbook, meet below error:
ValueError: time data 'Tue 2018-08-07 23:09:46 EDT' does not match format '%a %Y-%m-%d %H:%M:%S %Z'

Version-Release number of selected component (if applicable):
openshift-ansible-3.11.0-0.11.0.git.0.3c66516None.noarch.rpm

How reproducible:
always

Steps to Reproduce:
1. prepare the hosts file qe-inventory
2. ansible-playbook -i qe-inventory -l all,localhost ./openshift-ansible/playbooks/openshift-checks/adhoc.yml -e openshift_checks=sdn -e openshift_checks_output_dir=$HOME/tmp/aws/output


Actual results:
Failure summary:


  1. Hosts:    ec2-x-x-x-x.compute-1.amazonaws.com
     Play:     OpenShift Health Checks
     Task:     Run health checks (adhoc)
     Message:  One or more checks failed
     Details:  check "sdn":
               time data 'Tue 2018-08-07 23:09:46 EDT' does not match format '%a %Y-%m-%d %H:%M:%S %Z'
               Traceback (most recent call last):
                 File "/root/openshift-ansible/roles/openshift_health_checker/action_plugins/openshift_health_check.py", line 225, in run_check
                   result = check.run()
                 File "/root/openshift-ansible/roles/openshift_health_checker/openshift_checks/sdn.py", line 71, in run
                   self.check_node()
                 File "/root/openshift-ansible/roles/openshift_health_checker/openshift_checks/sdn.py", line 239, in check_node
                   self.save_service_logs('%s-node' % service_prefix)
                 File "/root/openshift-ansible/roles/openshift_health_checker/openshift_checks/sdn.py", line 341, in save_service_logs
                   '%a %Y-%m-%d %H:%M:%S %Z')
                 File "/usr/lib64/python2.7/_strptime.py", line 332, in _strptime
                   (data_string, format))
               ValueError: time data 'Tue 2018-08-07 23:09:46 EDT' does not match format '%a %Y-%m-%d %H:%M:%S %Z'


Expected results:
should not have the error

Additional info:
seems datetime.strptime() just can recognize timezone "UTC" "EST", but cannot understand "EDT".
for example: 
>>> start_timestamp = 'Tue 2018-08-07 23:09:38 UTC'
>>> since_date = datetime.datetime.strptime(start_timestamp, '%a %Y-%m-%d %H:%M:%S %Z')

Comment 1 Miciah Dashiel Butler Masters 2018-08-08 15:51:41 UTC
Thanks! Turns out Python's strptime cannot reliably parse time zones: https://bugs.python.org/issue22377

This was a particularly good find because the problem will only occur when the control machine and the target machine are using different time zones and the target machine's time zone is neither UTC nor GMT.

PR: https://github.com/openshift/openshift-ansible/pull/9482

Comment 3 Hongan Li 2018-08-23 09:50:07 UTC
verified in openshift-ansible-3.11.0-0.20.0.git.0.ec6d8caNone.noarch.rpm and the issue has been fixed.

Comment 5 errata-xmlrpc 2018-10-11 07:24:08 UTC
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, 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/RHBA-2018:2652


Note You need to log in before you can comment on or make changes to this bug.