Event lastTimestamp can be null starting with Kubernetes v1.16
See original GitHub issueche 2019-12-03 16:19:52,010[/172.27.0.1/...] [ERROR] [.w.i.k.n.KubernetesDeployments 500] -
Failed to parse last timestamp of the event.
Cause: Pod event timestamp can not be blank.
Event: PodEvent{
podName='mkdir-workspacemgb23y8056s2uxy7',
containerName='null',
reason='Scheduled',
message='Successfully assigned eclipse-example-workspace/mkdir-workspacemgb23y8056s2uxy7 to ripper1',
creationTimestamp='2019-12-03T15:48:20Z',
lastTimestamp='null'
}
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (7 by maintainers)
Top Results From Across the Web
Created event failed if 'eventTime' doesn't be set 'null'
Cluster information: Kubernetes version: v1.19.0 Cloud being used: ... eventTime or set it to null , the event will be created successfully.
Read more >Can kubectl describe show timestamp of pod events?
Note that it will still only give you firstTimestamp and lastTimestamp for each event. This will give the raw resources of the Event...
Read more >Events question (using Fabric8 Java client)
The best I can do is: this is trying, perhaps, to tell me that a Kubernetes Event describing the starting of a particular...
Read more >Event [v1] - Metadata APIs | OpenShift Container Platform 4.10
Event is a report of an event somewhere in the cluster. Events have a limited retention time and triggers and messages may evolve...
Read more >4.3 Observing cluster events via Event objects - 17哥
Because Events are standalone objects, you can list them using kubectl get events ... kind: Event lastTimestamp: "2020-05-17T18:16:40Z" message: Starting ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
As for this comment https://github.com/eclipse/che/issues/15395#issuecomment-593882859. After reviewing this pr https://github.com/kubernetes/kubernetes/pull/86557 and testing k8s client to 4.8.0 I’ve decided to go with variant 1 because the upgrade of the library didn’t help it only adds additional risk to delay the fix of this issue. Upgrade to the new k8s client would be made as a separate task.
Seeing hundreds of these error littered around our logs when workspaces start up. We have just upgraded from k8s 1.16 to 1.17 and both versions were leading to the same errors. It looks like the scheduling event doesn’t get a timestamp.
Could the absence of the timestamp cause unnecessary 60sec delays to workspace startup?