volcano.sh/volcano@v1.9.0/docs/design/minsuccess.md (about) 1 # MinSuccess 2 3 ## Motivation 4 5 Sometimes we want to deploy our job with some service tasks (nginx, redis and so on) which will always be in `Running` 6 state. So how to determine such kind job is completed? Only with `minAvailable` is not enough, because 7 `minAvailable` only work at **Job pending** and **all tasks Completed/Failed**. It lacks the ability to change the Job 8 state during the **Job is Running** state, and reclaim these service tasks. 9 10  11 12 ## Design 13 In order to solve this problem, we provide `minSuccess` field which will help the job to determine how many succeed 14 tasks does it need to change its state to `Completed`, and reclaim the other Running pods. 15 16 ```yaml 17 apiVersion: batch.volcano.sh/v1alpha1 18 kind: Job 19 metadata: 20 name: test-job 21 spec: 22 minAvailable: 6 23 minSuccess: 5 24 schedulerName: volcano 25 queue: default 26 plugins: 27 svc: [] 28 tasks: 29 - replicas: 5 30 name: "task" 31 template: 32 metadata: 33 name: task 34 spec: 35 containers: 36 - image: ubuntu 37 imagePullPolicy: IfNotPresent 38 name: task 39 resources: 40 requests: 41 cpu: "1" 42 restartPolicy: OnFailure 43 - replicas: 1 44 name: "redis" 45 template: 46 metadata: 47 name: redis 48 spec: 49 containers: 50 - image: redis 51 imagePullPolicy: IfNotPresent 52 name: redis 53 restartPolicy: OnFailure 54 ``` 55 56  57 58 From the above picture, we can find that when there are 5 tasks completed, the controller will know it's the time to mark the job `Completed`, and reclaim the redis pod.