1package v1
2
3import (
4 "cue.dev/x/k8s.io/apimachinery/pkg/apis/meta/v1"
5 v1_9 "cue.dev/x/k8s.io/api/core/v1"
6)
7
8// CronJob represents the configuration of a single cron job.
9#CronJob: {
10 // APIVersion defines the versioned schema of this representation
11 // of an object. Servers should convert recognized schemas to the
12 // latest internal value, and may reject unrecognized values.
13 // More info:
14 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
15 "apiVersion": "batch/v1"
16
17 // Kind is a string value representing the REST resource this
18 // object represents. Servers may infer this from the endpoint
19 // the client submits requests to. Cannot be updated. In
20 // CamelCase. More info:
21 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
22 "kind": "CronJob"
23
24 // Standard object's metadata. More info:
25 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
26 "metadata"?: v1.#ObjectMeta
27
28 // Specification of the desired behavior of a cron job, including
29 // the schedule. More info:
30 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
31 "spec"?: #CronJobSpec
32
33 // Current status of a cron job. More info:
34 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
35 "status"?: #CronJobStatus
36}
37
38// CronJobList is a collection of cron jobs.
39#CronJobList: {
40 // APIVersion defines the versioned schema of this representation
41 // of an object. Servers should convert recognized schemas to the
42 // latest internal value, and may reject unrecognized values.
43 // More info:
44 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
45 "apiVersion": "batch/v1"
46
47 // items is the list of CronJobs.
48 "items"!: [...#CronJob]
49
50 // Kind is a string value representing the REST resource this
51 // object represents. Servers may infer this from the endpoint
52 // the client submits requests to. Cannot be updated. In
53 // CamelCase. More info:
54 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
55 "kind": "CronJobList"
56
57 // Standard list metadata. More info:
58 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
59 "metadata"?: v1.#ListMeta
60}
61
62// CronJobSpec describes how the job execution will look like and
63// when it will actually run.
64#CronJobSpec: {
65 // Specifies how to treat concurrent executions of a Job. Valid
66 // values are:
67 //
68 // - "Allow" (default): allows CronJobs to run concurrently; -
69 // "Forbid": forbids concurrent runs, skipping next run if
70 // previous run hasn't finished yet; - "Replace": cancels
71 // currently running job and replaces it with a new one
72 "concurrencyPolicy"?: string
73
74 // The number of failed finished jobs to retain. Value must be
75 // non-negative integer. Defaults to 1.
76 "failedJobsHistoryLimit"?: int32 & int
77
78 // Specifies the job that will be created when executing a
79 // CronJob.
80 "jobTemplate"!: #JobTemplateSpec
81
82 // The schedule in Cron format, see
83 // https://en.wikipedia.org/wiki/Cron.
84 "schedule"!: string
85
86 // Optional deadline in seconds for starting the job if it misses
87 // scheduled time for any reason. Missed jobs executions will be
88 // counted as failed ones.
89 "startingDeadlineSeconds"?: int64 & int
90
91 // The number of successful finished jobs to retain. Value must be
92 // non-negative integer. Defaults to 3.
93 "successfulJobsHistoryLimit"?: int32 & int
94
95 // This flag tells the controller to suspend subsequent
96 // executions, it does not apply to already started executions.
97 // Defaults to false.
98 "suspend"?: bool
99
100 // The time zone name for the given schedule, see
101 // https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
102 // If not specified, this will default to the time zone of the
103 // kube-controller-manager process. The set of valid time zone
104 // names and the time zone offset is loaded from the system-wide
105 // time zone database by the API server during CronJob validation
106 // and the controller manager during execution. If no system-wide
107 // time zone database can be found a bundled version of the
108 // database is used instead. If the time zone name becomes
109 // invalid during the lifetime of a CronJob or due to a change in
110 // host configuration, the controller will stop creating new new
111 // Jobs and will create a system event with the reason
112 // UnknownTimeZone. More information can be found in
113 // https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zones
114 "timeZone"?: string
115}
116
117// CronJobStatus represents the current state of a cron job.
118#CronJobStatus: {
119 // A list of pointers to currently running jobs.
120 "active"?: [...v1_9.#ObjectReference]
121
122 // Information when was the last time the job was successfully
123 // scheduled.
124 "lastScheduleTime"?: v1.#Time
125
126 // Information when was the last time the job successfully
127 // completed.
128 "lastSuccessfulTime"?: v1.#Time
129}
130
131// Job represents the configuration of a single job.
132#Job: {
133 // APIVersion defines the versioned schema of this representation
134 // of an object. Servers should convert recognized schemas to the
135 // latest internal value, and may reject unrecognized values.
136 // More info:
137 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
138 "apiVersion": "batch/v1"
139
140 // Kind is a string value representing the REST resource this
141 // object represents. Servers may infer this from the endpoint
142 // the client submits requests to. Cannot be updated. In
143 // CamelCase. More info:
144 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
145 "kind": "Job"
146
147 // Standard object's metadata. More info:
148 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
149 "metadata"?: v1.#ObjectMeta
150
151 // Specification of the desired behavior of a job. More info:
152 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
153 "spec"?: #JobSpec
154
155 // Current status of a job. More info:
156 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
157 "status"?: #JobStatus
158}
159
160// JobCondition describes current state of a job.
161#JobCondition: {
162 // Last time the condition was checked.
163 "lastProbeTime"?: v1.#Time
164
165 // Last time the condition transit from one status to another.
166 "lastTransitionTime"?: v1.#Time
167
168 // Human readable message indicating details about last
169 // transition.
170 "message"?: string
171
172 // (brief) reason for the condition's last transition.
173 "reason"?: string
174
175 // Status of the condition, one of True, False, Unknown.
176 "status"!: string
177
178 // Type of job condition, Complete or Failed.
179 "type"!: string
180}
181
182// JobList is a collection of jobs.
183#JobList: {
184 // APIVersion defines the versioned schema of this representation
185 // of an object. Servers should convert recognized schemas to the
186 // latest internal value, and may reject unrecognized values.
187 // More info:
188 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
189 "apiVersion": "batch/v1"
190
191 // items is the list of Jobs.
192 "items"!: [...#Job]
193
194 // Kind is a string value representing the REST resource this
195 // object represents. Servers may infer this from the endpoint
196 // the client submits requests to. Cannot be updated. In
197 // CamelCase. More info:
198 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
199 "kind": "JobList"
200
201 // Standard list metadata. More info:
202 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
203 "metadata"?: v1.#ListMeta
204}
205
206// JobSpec describes how the job execution will look like.
207#JobSpec: {
208 // Specifies the duration in seconds relative to the startTime
209 // that the job may be continuously active before the system
210 // tries to terminate it; value must be positive integer. If a
211 // Job is suspended (at creation or through an update), this
212 // timer will effectively be stopped and reset when the Job is
213 // resumed again.
214 "activeDeadlineSeconds"?: int64 & int
215
216 // Specifies the number of retries before marking this job failed.
217 // Defaults to 6, unless backoffLimitPerIndex (only Indexed Job)
218 // is specified. When backoffLimitPerIndex is specified,
219 // backoffLimit defaults to 2147483647.
220 "backoffLimit"?: int32 & int
221
222 // Specifies the limit for the number of retries within an index
223 // before marking this index as failed. When enabled the number
224 // of failures per index is kept in the pod's
225 // batch.kubernetes.io/job-index-failure-count annotation. It can
226 // only be set when Job's completionMode=Indexed, and the Pod's
227 // restart policy is Never. The field is immutable.
228 "backoffLimitPerIndex"?: int32 & int
229
230 // completionMode specifies how Pod completions are tracked. It
231 // can be `NonIndexed` (default) or `Indexed`.
232 //
233 // `NonIndexed` means that the Job is considered complete when
234 // there have been .spec.completions successfully completed Pods.
235 // Each Pod completion is homologous to each other.
236 //
237 // `Indexed` means that the Pods of a Job get an associated
238 // completion index from 0 to (.spec.completions - 1), available
239 // in the annotation batch.kubernetes.io/job-completion-index.
240 // The Job is considered complete when there is one successfully
241 // completed Pod for each index. When value is `Indexed`,
242 // .spec.completions must be specified and `.spec.parallelism`
243 // must be less than or equal to 10^5. In addition, The Pod name
244 // takes the form `$(job-name)-$(index)-$(random-string)`, the
245 // Pod hostname takes the form `$(job-name)-$(index)`.
246 //
247 // More completion modes can be added in the future. If the Job
248 // controller observes a mode that it doesn't recognize, which is
249 // possible during upgrades due to version skew, the controller
250 // skips updates for the Job.
251 "completionMode"?: string
252
253 // Specifies the desired number of successfully finished pods the
254 // job should be run with. Setting to null means that the success
255 // of any pod signals the success of all pods, and allows
256 // parallelism to have any positive value. Setting to 1 means
257 // that parallelism is limited to 1 and the success of that pod
258 // signals the success of the job. More info:
259 // https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
260 "completions"?: int32 & int
261
262 // ManagedBy field indicates the controller that manages a Job.
263 // The k8s Job controller reconciles jobs which don't have this
264 // field at all or the field value is the reserved string
265 // `kubernetes.io/job-controller`, but skips reconciling Jobs
266 // with a custom value for this field. The value must be a valid
267 // domain-prefixed path (e.g. acme.io/foo) - all characters
268 // before the first "/" must be a valid subdomain as defined by
269 // RFC 1123. All characters trailing the first "/" must be valid
270 // HTTP Path characters as defined by RFC 3986. The value cannot
271 // exceed 63 characters. This field is immutable.
272 "managedBy"?: string
273
274 // manualSelector controls generation of pod labels and pod
275 // selectors. Leave `manualSelector` unset unless you are certain
276 // what you are doing. When false or unset, the system pick
277 // labels unique to this job and appends those labels to the pod
278 // template. When true, the user is responsible for picking
279 // unique labels and specifying the selector. Failure to pick a
280 // unique label may cause this and other jobs to not function
281 // correctly. However, You may see `manualSelector=true` in jobs
282 // that were created with the old `extensions/v1beta1` API. More
283 // info:
284 // https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#specifying-your-own-pod-selector
285 "manualSelector"?: bool
286
287 // Specifies the maximal number of failed indexes before marking
288 // the Job as failed, when backoffLimitPerIndex is set. Once the
289 // number of failed indexes exceeds this number the entire Job is
290 // marked as Failed and its execution is terminated. When left as
291 // null the job continues execution of all of its indexes and is
292 // marked with the `Complete` Job condition. It can only be
293 // specified when backoffLimitPerIndex is set. It can be null or
294 // up to completions. It is required and must be less than or
295 // equal to 10^4 when is completions greater than 10^5.
296 "maxFailedIndexes"?: int32 & int
297
298 // Specifies the maximum desired number of pods the job should run
299 // at any given time. The actual number of pods running in steady
300 // state will be less than this number when ((.spec.completions -
301 // .status.successful) < .spec.parallelism), i.e. when the work
302 // left to do is less than max parallelism. More info:
303 // https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
304 "parallelism"?: int32 & int
305
306 // Specifies the policy of handling failed pods. In particular, it
307 // allows to specify the set of actions and conditions which need
308 // to be satisfied to take the associated action. If empty, the
309 // default behaviour applies - the counter of failed pods,
310 // represented by the jobs's .status.failed field, is incremented
311 // and it is checked against the backoffLimit. This field cannot
312 // be used in combination with restartPolicy=OnFailure.
313 "podFailurePolicy"?: #PodFailurePolicy
314
315 // podReplacementPolicy specifies when to create replacement Pods.
316 // Possible values are: - TerminatingOrFailed means that we
317 // recreate pods
318 // when they are terminating (has a metadata.deletionTimestamp) or
319 // failed.
320 // - Failed means to wait until a previously created Pod is fully
321 // terminated (has phase
322 // Failed or Succeeded) before creating a replacement Pod.
323 //
324 // When using podFailurePolicy, Failed is the the only allowed
325 // value. TerminatingOrFailed and Failed are allowed values when
326 // podFailurePolicy is not in use.
327 "podReplacementPolicy"?: string
328
329 // A label query over pods that should match the pod count.
330 // Normally, the system sets this field for you. More info:
331 // https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
332 "selector"?: v1.#LabelSelector
333
334 // successPolicy specifies the policy when the Job can be declared
335 // as succeeded. If empty, the default behavior applies - the Job
336 // is declared as succeeded only when the number of succeeded
337 // pods equals to the completions. When the field is specified,
338 // it must be immutable and works only for the Indexed Jobs. Once
339 // the Job meets the SuccessPolicy, the lingering pods are
340 // terminated.
341 "successPolicy"?: #SuccessPolicy
342
343 // suspend specifies whether the Job controller should create Pods
344 // or not. If a Job is created with suspend set to true, no Pods
345 // are created by the Job controller. If a Job is suspended after
346 // creation (i.e. the flag goes from false to true), the Job
347 // controller will delete all active Pods associated with this
348 // Job. Users must design their workload to gracefully handle
349 // this. Suspending a Job will reset the StartTime field of the
350 // Job, effectively resetting the ActiveDeadlineSeconds timer
351 // too. Defaults to false.
352 "suspend"?: bool
353
354 // Describes the pod that will be created when executing a job.
355 // The only allowed template.spec.restartPolicy values are
356 // "Never" or "OnFailure". More info:
357 // https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
358 "template"!: v1_9.#PodTemplateSpec
359
360 // ttlSecondsAfterFinished limits the lifetime of a Job that has
361 // finished execution (either Complete or Failed). If this field
362 // is set, ttlSecondsAfterFinished after the Job finishes, it is
363 // eligible to be automatically deleted. When the Job is being
364 // deleted, its lifecycle guarantees (e.g. finalizers) will be
365 // honored. If this field is unset, the Job won't be
366 // automatically deleted. If this field is set to zero, the Job
367 // becomes eligible to be deleted immediately after it finishes.
368 "ttlSecondsAfterFinished"?: int32 & int
369}
370
371// JobStatus represents the current state of a Job.
372#JobStatus: {
373 // The number of pending and running pods which are not
374 // terminating (without a deletionTimestamp). The value is zero
375 // for finished jobs.
376 "active"?: int32 & int
377
378 // completedIndexes holds the completed indexes when
379 // .spec.completionMode = "Indexed" in a text format. The indexes
380 // are represented as decimal integers separated by commas. The
381 // numbers are listed in increasing order. Three or more
382 // consecutive numbers are compressed and represented by the
383 // first and last element of the series, separated by a hyphen.
384 // For example, if the completed indexes are 1, 3, 4, 5 and 7,
385 // they are represented as "1,3-5,7".
386 "completedIndexes"?: string
387
388 // Represents time when the job was completed. It is not
389 // guaranteed to be set in happens-before order across separate
390 // operations. It is represented in RFC3339 form and is in UTC.
391 // The completion time is set when the job finishes successfully,
392 // and only then. The value cannot be updated or removed. The
393 // value indicates the same or later point in time as the
394 // startTime field.
395 "completionTime"?: v1.#Time
396
397 // The latest available observations of an object's current state.
398 // When a Job fails, one of the conditions will have type
399 // "Failed" and status true. When a Job is suspended, one of the
400 // conditions will have type "Suspended" and status true; when
401 // the Job is resumed, the status of this condition will become
402 // false. When a Job is completed, one of the conditions will
403 // have type "Complete" and status true.
404 //
405 // A job is considered finished when it is in a terminal
406 // condition, either "Complete" or "Failed". A Job cannot have
407 // both the "Complete" and "Failed" conditions. Additionally, it
408 // cannot be in the "Complete" and "FailureTarget" conditions.
409 // The "Complete", "Failed" and "FailureTarget" conditions cannot
410 // be disabled.
411 //
412 // More info:
413 // https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
414 "conditions"?: [...#JobCondition]
415
416 // The number of pods which reached phase Failed. The value
417 // increases monotonically.
418 "failed"?: int32 & int
419
420 // FailedIndexes holds the failed indexes when
421 // spec.backoffLimitPerIndex is set. The indexes are represented
422 // in the text format analogous as for the `completedIndexes`
423 // field, ie. they are kept as decimal integers separated by
424 // commas. The numbers are listed in increasing order. Three or
425 // more consecutive numbers are compressed and represented by the
426 // first and last element of the series, separated by a hyphen.
427 // For example, if the failed indexes are 1, 3, 4, 5 and 7, they
428 // are represented as "1,3-5,7". The set of failed indexes cannot
429 // overlap with the set of completed indexes.
430 "failedIndexes"?: string
431
432 // The number of active pods which have a Ready condition and are
433 // not terminating (without a deletionTimestamp).
434 "ready"?: int32 & int
435
436 // Represents time when the job controller started processing a
437 // job. When a Job is created in the suspended state, this field
438 // is not set until the first time it is resumed. This field is
439 // reset every time a Job is resumed from suspension. It is
440 // represented in RFC3339 form and is in UTC.
441 //
442 // Once set, the field can only be removed when the job is
443 // suspended. The field cannot be modified while the job is
444 // unsuspended or finished.
445 "startTime"?: v1.#Time
446
447 // The number of pods which reached phase Succeeded. The value
448 // increases monotonically for a given spec. However, it may
449 // decrease in reaction to scale down of elastic indexed jobs.
450 "succeeded"?: int32 & int
451
452 // The number of pods which are terminating (in phase Pending or
453 // Running and have a deletionTimestamp).
454 //
455 // This field is beta-level. The job controller populates the
456 // field when the feature gate JobPodReplacementPolicy is enabled
457 // (enabled by default).
458 "terminating"?: int32 & int
459
460 // uncountedTerminatedPods holds the UIDs of Pods that have
461 // terminated but the job controller hasn't yet accounted for in
462 // the status counters.
463 //
464 // The job controller creates pods with a finalizer. When a pod
465 // terminates (succeeded or failed), the controller does three
466 // steps to account for it in the job status:
467 //
468 // 1. Add the pod UID to the arrays in this field. 2. Remove the
469 // pod finalizer. 3. Remove the pod UID from the arrays while
470 // increasing the corresponding
471 // counter.
472 //
473 // Old jobs might not be tracked using this field, in which case
474 // the field remains null. The structure is empty for finished
475 // jobs.
476 "uncountedTerminatedPods"?: #UncountedTerminatedPods
477}
478
479// JobTemplateSpec describes the data a Job should have when
480// created from a template
481#JobTemplateSpec: {
482 // Standard object's metadata of the jobs created from this
483 // template. More info:
484 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
485 "metadata"?: v1.#ObjectMeta
486
487 // Specification of the desired behavior of the job. More info:
488 // https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
489 "spec"?: #JobSpec
490}
491
492// PodFailurePolicy describes how failed pods influence the
493// backoffLimit.
494#PodFailurePolicy: {
495 // A list of pod failure policy rules. The rules are evaluated in
496 // order. Once a rule matches a Pod failure, the remaining of the
497 // rules are ignored. When no rule matches the Pod failure, the
498 // default handling applies - the counter of pod failures is
499 // incremented and it is checked against the backoffLimit. At
500 // most 20 elements are allowed.
501 "rules"!: [...#PodFailurePolicyRule]
502}
503
504// PodFailurePolicyOnExitCodesRequirement describes the
505// requirement for handling a failed pod based on its container
506// exit codes. In particular, it lookups the
507// .state.terminated.exitCode for each app container and init
508// container status, represented by the .status.containerStatuses
509// and .status.initContainerStatuses fields in the Pod status,
510// respectively. Containers completed with success (exit code 0)
511// are excluded from the requirement check.
512#PodFailurePolicyOnExitCodesRequirement: {
513 // Restricts the check for exit codes to the container with the
514 // specified name. When null, the rule applies to all containers.
515 // When specified, it should match one the container or
516 // initContainer names in the pod template.
517 "containerName"?: string
518
519 // Represents the relationship between the container exit code(s)
520 // and the specified values. Containers completed with success
521 // (exit code 0) are excluded from the requirement check.
522 // Possible values are:
523 //
524 // - In: the requirement is satisfied if at least one container
525 // exit code
526 // (might be multiple if there are multiple containers not
527 // restricted
528 // by the 'containerName' field) is in the set of specified
529 // values.
530 // - NotIn: the requirement is satisfied if at least one container
531 // exit code
532 // (might be multiple if there are multiple containers not
533 // restricted
534 // by the 'containerName' field) is not in the set of specified
535 // values.
536 // Additional values are considered to be added in the future.
537 // Clients should react to an unknown operator by assuming the
538 // requirement is not satisfied.
539 "operator"!: string
540
541 // Specifies the set of values. Each returned container exit code
542 // (might be multiple in case of multiple containers) is checked
543 // against this set of values with respect to the operator. The
544 // list of values must be ordered and must not contain
545 // duplicates. Value '0' cannot be used for the In operator. At
546 // least one element is required. At most 255 elements are
547 // allowed.
548 "values"!: [...int32 & int]
549}
550
551// PodFailurePolicyOnPodConditionsPattern describes a pattern for
552// matching an actual pod condition type.
553#PodFailurePolicyOnPodConditionsPattern: {
554 // Specifies the required Pod condition status. To match a pod
555 // condition it is required that the specified status equals the
556 // pod condition status. Defaults to True.
557 "status"?: string
558
559 // Specifies the required Pod condition type. To match a pod
560 // condition it is required that specified type equals the pod
561 // condition type.
562 "type"!: string
563}
564
565// PodFailurePolicyRule describes how a pod failure is handled
566// when the requirements are met. One of onExitCodes and
567// onPodConditions, but not both, can be used in each rule.
568#PodFailurePolicyRule: {
569 // Specifies the action taken on a pod failure when the
570 // requirements are satisfied. Possible values are:
571 //
572 // - FailJob: indicates that the pod's job is marked as Failed and
573 // all
574 // running pods are terminated.
575 // - FailIndex: indicates that the pod's index is marked as Failed
576 // and will
577 // not be restarted.
578 // - Ignore: indicates that the counter towards the .backoffLimit
579 // is not
580 // incremented and a replacement pod is created.
581 // - Count: indicates that the pod is handled in the default way -
582 // the
583 // counter towards the .backoffLimit is incremented.
584 // Additional values are considered to be added in the future.
585 // Clients should react to an unknown action by skipping the
586 // rule.
587 "action"!: string
588
589 // Represents the requirement on the container exit codes.
590 "onExitCodes"?: #PodFailurePolicyOnExitCodesRequirement
591
592 // Represents the requirement on the pod conditions. The
593 // requirement is represented as a list of pod condition
594 // patterns. The requirement is satisfied if at least one pattern
595 // matches an actual pod condition. At most 20 elements are
596 // allowed.
597 "onPodConditions"?: [...#PodFailurePolicyOnPodConditionsPattern]
598}
599
600// SuccessPolicy describes when a Job can be declared as succeeded
601// based on the success of some indexes.
602#SuccessPolicy: {
603 // rules represents the list of alternative rules for the
604 // declaring the Jobs as successful before `.status.succeeded >=
605 // .spec.completions`. Once any of the rules are met, the
606 // "SuccessCriteriaMet" condition is added, and the lingering
607 // pods are removed. The terminal state for such a Job has the
608 // "Complete" condition. Additionally, these rules are evaluated
609 // in order; Once the Job meets one of the rules, other rules are
610 // ignored. At most 20 elements are allowed.
611 "rules"!: [...#SuccessPolicyRule]
612}
613
614// SuccessPolicyRule describes rule for declaring a Job as
615// succeeded. Each rule must have at least one of the
616// "succeededIndexes" or "succeededCount" specified.
617#SuccessPolicyRule: {
618 // succeededCount specifies the minimal required size of the
619 // actual set of the succeeded indexes for the Job. When
620 // succeededCount is used along with succeededIndexes, the check
621 // is constrained only to the set of indexes specified by
622 // succeededIndexes. For example, given that succeededIndexes is
623 // "1-4", succeededCount is "3", and completed indexes are "1",
624 // "3", and "5", the Job isn't declared as succeeded because only
625 // "1" and "3" indexes are considered in that rules. When this
626 // field is null, this doesn't default to any value and is never
627 // evaluated at any time. When specified it needs to be a
628 // positive integer.
629 "succeededCount"?: int32 & int
630
631 // succeededIndexes specifies the set of indexes which need to be
632 // contained in the actual set of the succeeded indexes for the
633 // Job. The list of indexes must be within 0 to
634 // ".spec.completions-1" and must not contain duplicates. At
635 // least one element is required. The indexes are represented as
636 // intervals separated by commas. The intervals can be a decimal
637 // integer or a pair of decimal integers separated by a hyphen.
638 // The number are listed in represented by the first and last
639 // element of the series, separated by a hyphen. For example, if
640 // the completed indexes are 1, 3, 4, 5 and 7, they are
641 // represented as "1,3-5,7". When this field is null, this field
642 // doesn't default to any value and is never evaluated at any
643 // time.
644 "succeededIndexes"?: string
645}
646
647// UncountedTerminatedPods holds UIDs of Pods that have terminated
648// but haven't been accounted in Job status counters.
649#UncountedTerminatedPods: {
650 // failed holds UIDs of failed Pods.
651 "failed"?: [...string]
652
653 // succeeded holds UIDs of succeeded Pods.
654 "succeeded"?: [...string]
655}