diff --git a/deploy/charts/approver-policy/values.schema.json b/deploy/charts/approver-policy/values.schema.json index b6a989fe..782087dd 100644 --- a/deploy/charts/approver-policy/values.schema.json +++ b/deploy/charts/approver-policy/values.schema.json @@ -48,6 +48,9 @@ "resources": { "$ref": "#/$defs/helm-values.resources" }, + "strategy": { + "$ref": "#/$defs/helm-values.strategy" + }, "tolerations": { "$ref": "#/$defs/helm-values.tolerations" }, @@ -444,6 +447,11 @@ "description": "Kubernetes pod resources.\nFor more information, see [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).\n\nFor example:\nresources:\n limits:\n cpu: 100m\n memory: 128Mi\n requests:\n cpu: 100m\n memory: 128Mi", "type": "object" }, + "helm-values.strategy": { + "default": {}, + "description": "Deployment update strategy for the approver-policy Deployment.\n\nThis could be needed when deploying approver-policy on each control-plane node and setting anti-affinities to forbid two pods on the same node. In this situation, default values of maxSurge (25% round up to next integer = 1) and maxUnavailable (25% round down to next integer = 0) block the rolling update as the new surge pod can't be scheduled on a control-plane node due to anti-affinities. Setting maxSurge to 0 and maxUnavailable to 1 would solve the problem.\n\nFor example:\nstrategy:\n type: RollingUpdate\n rollingUpdate:\n maxSurge: 0\n maxUnavailable: 1\nFor more information, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy).", + "type": "object" + }, "helm-values.tolerations": { "default": [], "description": "A list of Kubernetes Tolerations, if required. For more information, see [Toleration v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#toleration-v1-core).\n\nFor example:\ntolerations:\n- key: foo.bar.com/role\n operator: Equal\n value: master\n effect: NoSchedule",