Bug 1690557 - Installer should mount localtime in master pods so cron jobs run based on masters local time
Summary: Installer should mount localtime in master pods so cron jobs run based on mas...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 3.10.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.10.z
Assignee: Russell Teague
QA Contact: Weihua Meng
URL:
Whiteboard:
: 1717840 (view as bug list)
Depends On: 1674170
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-19 16:54 UTC by Ryan Howe
Modified: 2019-08-21 13:52 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, timezone configuration was not mounted into the control plane static pods which led to logging timestamps not aligning with all other system logs. The host's timezone configuration is now mounted into the control plane pods.
Clone Of:
Environment:
Last Closed: 2019-08-21 13:52:05 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2509 None None None 2019-08-21 13:52:09 UTC

Description Ryan Howe 2019-03-19 16:54:32 UTC
Description of problem:

When cron jobs are run the time of the master controller is used. Since 3.10+ the service is run in a container and does not get the correct local time. 

https://docs.openshift.com/container-platform/3.10/dev_guide/cron_jobs.html#creating-a-cronjob



Additional info:

Mount /etc/localtime in the controller pods. 

https://github.com/openshift/openshift-ansible/blob/release-3.10/roles/openshift_control_plane/tasks/static.yml#L98

https://github.com/openshift/openshift-ansible/blob/release-3.11/roles/openshift_control_plane/files/controller.yaml#L30


# tail -n 37 /etc/origin/node/pods/controller.yaml 
    volumeMounts:
...
    - mountPath: /etc/localtime
      name: localtime
  volumes:
...
  - hostPath:
      path: /etc/localtime
    name: localtime

Comment 1 Scott Dodson 2019-03-19 17:27:19 UTC
Nothing the installer can/should do about this.

Comment 3 Scott Dodson 2019-03-19 18:59:00 UTC
I don't think that bug did anything to address cron jobs, only apiserver and controllers. Won't the cron jobs start a new pod that likely won't have /etc/localtime mounted up?

Comment 4 Ryan Howe 2019-03-19 21:12:57 UTC
Cronjobs are scheduled based on the local time of the master controller, in 3.10 we do not mount /etc/localtime  in the master pods.

Comment 5 Scott Dodson 2019-03-19 21:26:19 UTC
Sorry, I misinterpreted the bug to mean that the logs in the cron job based pods were incorrect. 

https://github.com/openshift/openshift-ansible/pull/11373 to backport this to 3.10, we should look into this noted problem before doing so however

https://github.com/openshift/cluster-monitoring-operator/issues/279

Comment 6 Russell Teague 2019-06-06 14:58:55 UTC
https://github.com/openshift/openshift-ansible/pull/11373 is merged

Comment 7 Russell Teague 2019-06-06 15:01:02 UTC
*** Bug 1717840 has been marked as a duplicate of this bug. ***

Comment 9 Weihua Meng 2019-06-17 12:53:52 UTC
Failed.
openshift-ansible-3.10.149-1.git.0.eb0262c.el7

Seems mount does not handle link as expected.

There is no difference mount or not mount hostPath /etc/localtime

[root@ip-172-18-10-138 ~]# oc rsh pod/master-api-ip-172-18-10-138.ec2.internal
sh-4.2# ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 25 May 30 11:31 /etc/localtime -> ../usr/share/zoneinfo/UTC
sh-4.2# exit
[root@ip-172-18-10-138 ~]# ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 38 Jun 16 18:22 /etc/localtime -> ../usr/share/zoneinfo/America/New_York

Comment 13 Weihua Meng 2019-08-02 08:57:29 UTC
Fixed.
openshift-ansible-3.10.153-1.git.0.2363fa8.el7

Time in master controller/apiserver pod is the same with the host.

Although ls -l /etc/localtime in pod is different with it on host as comment 9 .

Comment 15 errata-xmlrpc 2019-08-21 13:52:05 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-2019:2509


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