[MOSIP-28488] Updated backoffLimit.

mosip · Jul 21, 2023 · 42e3dd6 · 42e3dd6
1 parent 823d854
commit 42e3dd6
Show file tree

Hide file tree

Showing 4 changed files with 10 additions and 2 deletions.
diff --git a/charts/apitestrig/templates/cronjob.yaml b/charts/apitestrig/templates/cronjob.yaml
@@ -15,7 +15,7 @@ spec:
   schedule: {{ $.Values.crontime }}
   jobTemplate:
     spec:
-      backoffLimit: 0 # this has very low chance of failing, as all this does
+      backoffLimit: {{ .Values.backoffLimit }} # this has very low chance of failing, as all this does
                       # is prompt kubernetes to schedule new replica set for
       # the deployment
       # activeDeadlineSeconds: 600 # timeout, makes most sense with

diff --git a/charts/apitestrig/values.yaml b/charts/apitestrig/values.yaml
@@ -194,6 +194,10 @@ customLivenessProbe: {}
 ##
 customReadinessProbe: {}
 
+## "backoff" strategy - It is used when dealing with resources that are retrying or recovering from failures.
+##
+backoffLimit: 0
+
 ## Update strategy - only really applicable for deployments with RWO PVs attached
 ## If replicas = 1, an update can get "stuck", as the previous pod remains attached to the
 ## PV, and the "incoming" pod can never start. Changing the strategy to "Recreate" will

diff --git a/charts/dslorchestrator/templates/cronjob.yaml b/charts/dslorchestrator/templates/cronjob.yaml
@@ -13,7 +13,7 @@ spec:
   schedule: {{ .Values.crontime }}
   jobTemplate:
     spec:
-      backoffLimit: 0 # this has very low chance of failing, as all this does
+      backoffLimit: {{ .Values.backoffLimit }} # this has very low chance of failing, as all this does
                       # is prompt kubernetes to schedule new replica set for
       # the deployment
       # activeDeadlineSeconds: 600 # timeout, makes most sense with

diff --git a/charts/dslorchestrator/values.yaml b/charts/dslorchestrator/values.yaml
@@ -194,6 +194,10 @@ customLivenessProbe: {}
 ##
 customReadinessProbe: {}
 
+## "backoff" strategy - It is used when dealing with resources that are retrying or recovering from failures.
+##
+backoffLimit: 0
+
 ## Update strategy - only really applicable for deployments with RWO PVs attached
 ## If replicas = 1, an update can get "stuck", as the previous pod remains attached to the
 ## PV, and the "incoming" pod can never start. Changing the strategy to "Recreate" will