Bug 1690557

Summary: Installer should mount localtime in master pods so cron jobs run based on masters local time
Product: OpenShift Container Platform Reporter: Ryan Howe <rhowe>
Component: InstallerAssignee: Russell Teague <rteague>
Installer sub component: openshift-ansible QA Contact: Weihua Meng <wmeng>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: aos-bugs, aprajapa, dcaldwel, fgrosjea, gpei, jokerman, mmccomas, rteague, wmeng
Version: 3.10.0Keywords: Reopened
Target Milestone: ---   
Target Release: 3.10.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-21 13:52:05 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:
Bug Depends On: 1674170    
Bug Blocks:    

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