docker/buildx
1
0
Fork 0
mirror of https://gitea.com/Lydanne/buildx.git synced 2025-07-09 21:17:09 +08:00
Code Issues Packages Projects Releases 1 Wiki Activity

vendor: bump k8s to v0.25.4

Browse Source 
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
This commit is contained in:
CrazyMax
2023-03-14 18:20:37 +01:00
parent 4a73abfd64
commit cfa6b4f7c8
889 changed files with 96934 additions and 11708 deletions
Download Patch File Download Diff File Expand all files Collapse all files

140
vendor/k8s.io/api/batch/v1/generated.proto generated vendored
View File

@ -27,7 +27,7 @@ import "k8s.io/apimachinery/pkg/runtime/generated.proto";
import "k8s.io/apimachinery/pkg/runtime/schema/generated.proto";
// Package-wide variables from generator "generated".
option go_package = "v1";
option go_package = "k8s.io/api/batch/v1";
// CronJob represents the configuration of a single cron job.
message CronJob {
@ -63,6 +63,19 @@ message CronJobSpec {
// The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.
optional string schedule = 1;
// The time zone name for the given schedule, see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
// If not specified, this will default to the time zone of the kube-controller-manager process.
// The set of valid time zone names and the time zone offset is loaded from the system-wide time zone
// database by the API server during CronJob validation and the controller manager during execution.
// If no system-wide time zone database can be found a bundled version of the database is used instead.
// If the time zone name becomes invalid during the lifetime of a CronJob or due to a change in host
// configuration, the controller will stop creating new new Jobs and will create a system event with the
// reason UnknownTimeZone.
// More information can be found in https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zones
// This is beta field and must be enabled via the `CronJobTimeZone` feature gate.
// +optional
optional string timeZone = 8;
// Optional deadline in seconds for starting the job if it misses scheduled
// time for any reason. Missed jobs executions will be counted as failed ones.
// +optional
@ -192,6 +205,19 @@ message JobSpec {
// +optional
optional int64 activeDeadlineSeconds = 3;
// Specifies the policy of handling failed pods. In particular, it allows to
// specify the set of actions and conditions which need to be
// satisfied to take the associated action.
// If empty, the default behaviour applies - the counter of failed pods,
// represented by the jobs's .status.failed field, is incremented and it is
// checked against the backoffLimit. This field cannot be used in combination
// with restartPolicy=OnFailure.
//
// This field is alpha-level. To use this field, you must enable the
// `JobPodFailurePolicy` feature gate (disabled by default).
// +optional
optional PodFailurePolicy podFailurePolicy = 11;
// Specifies the number of retries before marking this job failed.
// Defaults to 6
// +optional
@ -227,8 +253,6 @@ message JobSpec {
// guarantees (e.g. finalizers) will be honored. If this field is unset,
// the Job won't be automatically deleted. If this field is set to zero,
// the Job becomes eligible to be deleted immediately after it finishes.
// This field is alpha-level and is only honored by servers that enable the
// TTLAfterFinished feature.
// +optional
optional int32 ttlSecondsAfterFinished = 8;
@ -250,9 +274,10 @@ message JobSpec {
// `$(job-name)-$(index)-$(random-string)`,
// the Pod hostname takes the form `$(job-name)-$(index)`.
//
// This field is beta-level. More completion modes can be added in the future.
// If the Job controller observes a mode that it doesn't recognize, the
// controller skips updates for the Job.
// More completion modes can be added in the future.
// If the Job controller observes a mode that it doesn't recognize, which
// is possible during upgrades due to version skew, the controller
// skips updates for the Job.
// +optional
optional string completionMode = 9;
@ -264,9 +289,6 @@ message JobSpec {
// Suspending a Job will reset the StartTime field of the Job, effectively
// resetting the ActiveDeadlineSeconds timer too. Defaults to false.
//
// This field is beta-level, gated by SuspendJob feature flag (enabled by
// default).
//
// +optional
optional bool suspend = 10;
}
@ -300,7 +322,7 @@ message JobStatus {
// +optional
optional k8s.io.apimachinery.pkg.apis.meta.v1.Time completionTime = 3;
// The number of actively running pods.
// The number of pending and running pods.
// +optional
optional int32 active = 4;
@ -333,12 +355,20 @@ message JobStatus {
// (3) Remove the pod UID from the arrays while increasing the corresponding
// counter.
//
// This field is alpha-level. The job controller only makes use of this field
// when the feature gate PodTrackingWithFinalizers is enabled.
// This field is beta-level. The job controller only makes use of this field
// when the feature gate JobTrackingWithFinalizers is enabled (enabled
// by default).
// Old jobs might not be tracked using this field, in which case the field
// remains null.
// +optional
optional UncountedTerminatedPods uncountedTerminatedPods = 8;
// The number of pods which have a Ready condition.
//
// This field is beta-level. The job controller populates the field when
// the feature gate JobReadyPods is enabled (enabled by default).
// +optional
optional int32 ready = 9;
}
// JobTemplateSpec describes the data a Job should have when created from a template
@ -354,6 +384,92 @@ message JobTemplateSpec {
optional JobSpec spec = 2;
}
// PodFailurePolicy describes how failed pods influence the backoffLimit.
message PodFailurePolicy {
// A list of pod failure policy rules. The rules are evaluated in order.
// Once a rule matches a Pod failure, the remaining of the rules are ignored.
// When no rule matches the Pod failure, the default handling applies - the
// counter of pod failures is incremented and it is checked against
// the backoffLimit. At most 20 elements are allowed.
// +listType=atomic
repeated PodFailurePolicyRule rules = 1;
}
// PodFailurePolicyOnExitCodesRequirement describes the requirement for handling
// a failed pod based on its container exit codes. In particular, it lookups the
// .state.terminated.exitCode for each app container and init container status,
// represented by the .status.containerStatuses and .status.initContainerStatuses
// fields in the Pod status, respectively. Containers completed with success
// (exit code 0) are excluded from the requirement check.
message PodFailurePolicyOnExitCodesRequirement {
// Restricts the check for exit codes to the container with the
// specified name. When null, the rule applies to all containers.
// When specified, it should match one the container or initContainer
// names in the pod template.
// +optional
optional string containerName = 1;
// Represents the relationship between the container exit code(s) and the
// specified values. Containers completed with success (exit code 0) are
// excluded from the requirement check. Possible values are:
// - In: the requirement is satisfied if at least one container exit code
// (might be multiple if there are multiple containers not restricted
// by the 'containerName' field) is in the set of specified values.
// - NotIn: the requirement is satisfied if at least one container exit code
// (might be multiple if there are multiple containers not restricted
// by the 'containerName' field) is not in the set of specified values.
// Additional values are considered to be added in the future. Clients should
// react to an unknown operator by assuming the requirement is not satisfied.
optional string operator = 2;
// Specifies the set of values. Each returned container exit code (might be
// multiple in case of multiple containers) is checked against this set of
// values with respect to the operator. The list of values must be ordered
// and must not contain duplicates. Value '0' cannot be used for the In operator.
// At least one element is required. At most 255 elements are allowed.
// +listType=set
repeated int32 values = 3;
}
// PodFailurePolicyOnPodConditionsPattern describes a pattern for matching
// an actual pod condition type.
message PodFailurePolicyOnPodConditionsPattern {
// Specifies the required Pod condition type. To match a pod condition
// it is required that specified type equals the pod condition type.
optional string type = 1;
// Specifies the required Pod condition status. To match a pod condition
// it is required that the specified status equals the pod condition status.
// Defaults to True.
optional string status = 2;
}
// PodFailurePolicyRule describes how a pod failure is handled when the requirements are met.
// One of OnExitCodes and onPodConditions, but not both, can be used in each rule.
message PodFailurePolicyRule {
// Specifies the action taken on a pod failure when the requirements are satisfied.
// Possible values are:
// - FailJob: indicates that the pod's job is marked as Failed and all
// running pods are terminated.
// - Ignore: indicates that the counter towards the .backoffLimit is not
// incremented and a replacement pod is created.
// - Count: indicates that the pod is handled in the default way - the
// counter towards the .backoffLimit is incremented.
// Additional values are considered to be added in the future. Clients should
// react to an unknown action by skipping the rule.
optional string action = 1;
// Represents the requirement on the container exit codes.
// +optional
optional PodFailurePolicyOnExitCodesRequirement onExitCodes = 2;
// Represents the requirement on the pod conditions. The requirement is represented
// as a list of pod condition patterns. The requirement is satisfied if at
// least one pattern matches an actual pod condition. At most 20 elements are allowed.
// +listType=atomic
repeated PodFailurePolicyOnPodConditionsPattern onPodConditions = 3;
}
// UncountedTerminatedPods holds UIDs of Pods that have terminated but haven't
// been accounted in Job status counters.
message UncountedTerminatedPods {