Bug 1659360

Summary: oc get event -w no longer produce absolute timestamp
Product: OpenShift Container Platform Reporter: Takayoshi Kimura <tkimura>
Component: ocAssignee: Juan Vallejo <jvallejo>
Status: CLOSED DUPLICATE QA Contact: Xingxing Xia <xxia>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.11.0CC: aos-bugs, jokerman, mmccomas
Target Milestone: ---   
Target Release: ---   
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: 2018-12-17 04:55:03 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:

Description Takayoshi Kimura 2018-12-14 08:05:01 UTC
Description of problem:

In 3.11, oc get event -w no longer produce absolute timestamp.

> $ oc get events -w
> LAST SEEN   FIRST SEEN   COUNT     NAME                                     KIND                    SUBOBJECT                        TYPE      REASON             SOURCE                                        MESSAGE
> 13s         13s          1         hello-sinatra-1-sjzh6.1570235fa5b7170e   Pod                                                      Normal    Scheduled          default-scheduler                             Successfully assigned test-event/hello-sinatra-1-sjzh6 to tkimura-sandbox.usersys.redhat.com
> 10s         10s          1         hello-sinatra-1-sjzh6.1570236049209e46   Pod                     spec.containers{hello-sinatra}   Normal    Pulling            kubelet, tkimura-sandbox.usersys.redhat.com   pulling image "docker-registry.default.svc:5000/test-event/hello-sinatra@sha256:7857788bbff39cf07a0777ec0c6780711aa41ac621adf2fd79c89870b87a12b1"
> 9s          9s           1         hello-sinatra-1-sjzh6.1570236062250392   Pod                     spec.containers{hello-sinatra}   Normal    Pulled             kubelet, tkimura-sandbox.usersys.redhat.com   Successfully pulled image "docker-registry.default.svc:5000/test-event/hello-sinatra@sha256:7857788bbff39cf07a0777ec0c6780711aa41ac621adf2fd79c89870b87a12b1"
> 9s          9s           1         hello-sinatra-1-sjzh6.1570236068253496   Pod                     spec.containers{hello-sinatra}   Normal    Created            kubelet, tkimura-sandbox.usersys.redhat.com   Created container
> 9s          9s           1         hello-sinatra-1-sjzh6.1570236079118922   Pod                     spec.containers{hello-sinatra}   Normal    Started            kubelet, tkimura-sandbox.usersys.redhat.com   Started container
> 12s         12s          1         hello-sinatra-1-sxx4c.1570235faf75f777   Pod                     spec.containers{hello-sinatra}   Normal    Killing            kubelet, tkimura-sandbox.usersys.redhat.com   Killing container with id docker://hello-sinatra:Need to kill Pod
> 13s         13s          1         hello-sinatra-1.1570235fa4af0385         ReplicationController                                    Normal    SuccessfulCreate   replication-controller                        Created pod: hello-sinatra-1-sjzh6

Previously it does:

> $ oc get events -w
> LAST SEEN                       FIRST SEEN                      COUNT     NAME                             KIND                    SUBOBJECT   TYPE      REASON                  SOURCE                            MESSAGE
> 2018-12-14 16:51:13 +0900 JST   2018-12-14 16:51:13 +0900 JST   1         sleep-1-cwfjr.157023a7312a611c   Pod                                 Normal    Scheduled               default-scheduler                 Successfully assigned sleep-1-cwfjr to s39.usersys.redhat.com

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

$ oc version
oc v3.11.51
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO

All 3.11 oc versions.

How reproducible:

Always

Steps to Reproduce:
1.
2.
3.

Actual results:

LAST SEEN, FIRST SEEN are not absolute timestamp

Expected results:

LAST SEEN, FIRST SEEN shows absolute timestamp

Additional info:

Comment 1 Xingxing Xia 2018-12-17 04:55:03 UTC

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