-
Sub-task
-
Resolution: Done
-
Undefined
-
None
-
None
-
None
-
False
-
-
False
-
ToDo
-
-
-
0
-
0
-
Very Likely
-
0
-
None
-
Unset
-
Unknown
Description of problem:
When fs-backup-timeout is tried to set as 120m as string value as per velero document in DPA as below then it is throwing error:
DPA:
~~~
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: velero
namespace: openshift-adp
spec:
[..]
configuration:
[..]
velero:
args:
fs-backup-timeout: 120m
~~~
Error:
~~~
spec.configuration.velero.args.fs-backup-timeout: Invalid value: "string": spec.configuration.velero.args.fs-backup-timeout in body must be of type integer: "string"
~~~
If we set only integer value like 120 then velero deployment gets set with 120ns i.e. nanosecond which would be too low.
Velero deployment if we set integer value:
~~~
spec:
containers:
- args:
- server
- --fs-backup-timeout=120ns
~~~
When we set fs-backup-timeout: 7200000000000 then velero deployment gets set as 2 hours.
~~~
spec:
containers:
- args:
- server
- --fs-backup-timeout=2h0m0s
~~~
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. Try to add fs-backup-timeout argument as 120m or 2h in DPA for velero configuration as shown in description with oc edit dpa command.
2. Edit will fail and show the error.
Actual results:
DPA edit fails if we mention string value for fs-backup-timeout argument and only accepts integer value. If integer value is set then velero deployment takes it as nanoseconds.
Expected results:
DPA should allow mentioning string values for fs-backup-timeout argument in velero configuration which are easy to set like 120m i.e. 120 minutes or 2h i.e. 2 hours. This is allowed in actual velero deployment.
Additional info: