cue.dev/x/k8s.io@v0.7.0

api/batch/v1/schema.cue raw

  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}