// checked against the backoffLimit. This field cannot be used in combination
	// with restartPolicy=OnFailure.
	//
	// This field is beta-level. It can be used when the `JobPodFailurePolicy`
	// feature gate is enabled (enabled by default).
	// +optional
	PodFailurePolicy *PodFailurePolicy `json:"podFailurePolicy,omitempty" protobuf:"bytes,11,opt,name=podFailurePolicy"`

	// checked against the backoffLimit. This field cannot be used in combination
	// with .spec.podTemplate.spec.restartPolicy=OnFailure.
	//
	// This field is beta-level. It can be used when the `JobPodFailurePolicy`
	// feature gate is enabled (enabled by default).
	// +optional
	PodFailurePolicy *PodFailurePolicy

	// successPolicy specifies the policy when the Job can be declared as succeeded.

  phase (Succeeded or Failed, depending on the exit statuses of the pod containers) to pods which
  are deleted while running.
  
  This fixes the issue for jobs using pod failure policy (with JobPodFailurePolicy and PodDisruptionConditions 
  feature gates enabled) that their pods could get stuck in the pending phase when deleted.
  
  Users who maintain controllers which relied on the fact that pods with RestartPolicy=Always

- When the feature gates `PodDisruptionConditions` and `JobPodFailurePolicy` are both enabled,
  the Job controller now does not consider a terminating Pod (a pod that has a `.metadata.deletionTimestamp`)
  as a failure until that Pod is terminal (its `.status.phase` is `Failed` or `Succeeded`).

          },
          "podReplacementPolicy": {

        },
        "selector": {
          "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelector",

							Ref:         ref("k8s.io/api/batch/v1.PodFailurePolicy"),
						},
					},
					"successPolicy": {
						SchemaProps: spec.SchemaProps{

        },
        "podReplacementPolicy": {