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