-
Bug
-
Resolution: Done
-
Major
-
None
-
False
-
-
False
-
QE - Ack
-
oadp-velero-container-1.1.4-1
-
ToDo
-
-
-
0
-
0
-
Very Likely
-
0
-
Customer Escalated, Customer Facing
-
None
-
Unset
-
Unknown
-
No
Validation Steps
Set env TZ like so to desired timezone.
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample namespace: openshift-adp spec: configuration: velero: podConfig: env: - name: TZ value: America/New_York
Notice in velero pod logs that timestamps now include offsets from UTC seen here `-04:00`
time="2023-03-14T10:57:24-04:00" level=info msg="Starting Velero server v1.9.5-OADP (-)" logSource="/remote-source/velero/app/pkg/cmd/server/server.go:183"
Create a schedule
Notice in velero pod logs that backup generated name has the exact same hour/minute numbers
Seen below 2023-03-14T11:00:04 matches up with 20230314110004
time="2023-03-14T11:00:04-04:00" level=info msg="No Schedule.template.metadata.labels set - using Schedule.labels for backup object" backup=openshift-adp/schedule-20230314110004 labels="map[]"
Description of problem:
In this case: TimeZone
Customer Issue is here: Please read! https://access.redhat.com/support/cases/#/case/03405780
https://github.com/vmware-tanzu/velero/pull/2944
We could ensure the oadp-controller also has the TZ config or we could better handle any env config available to velero container running in docker.
Notes from Emily:
Emily 12:34 PM
I wonder if we could append it to the velero container here: https://github.com/openshift/oadp-operator/blob/master/controllers/velero.go#L486 (edited)
maybe could do something like add the value to the OADP api in the velero config (what Dylan pointed out). Write a func to check whether or not that value is set. If so, append that env var with the value in DPA to the velero container
Notes from Dylan:
https://github.com/openshift/oadp-operator/blob/master/api/v1alpha1/oadp_types.go#L66
basically just add it here
Which version we'll fix this in is TBD.