jiebi/CodeConvo huggingface dataset:
Code change:
for a PodFailurePolicyRule. However, when trying to create a JobSet programmatically with a JobTemplate that defines a PodFailurePolicy rule for failing a job immediately if the failed pod had condition DisruptionTarget, I get a validation error indicating that cannot be null. I've tried using both and (with matching versions for package as well). Error: JobSet spec: JobTemplate passes validation. JobSet: applying example JobSet in the description of this issue. JobSet: and applying example JobSet in the description of this issue. No response 30 (tests on a kind cluster using kindest/node:v1.30.0) <details</details<details</details<details</details<details</details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc
/assign
I confirmed the issue, moreover, I see that when the JobSet webhook is disabled then it works ok, I think it must be the JobSet webhook which adds the "onExitCodes" field during deserializion /serialization step. I can also see that when I rebuild JobSet using kubernetes field "onExitCodes" with "omitempty", then it the JobSet creates ok. I will open a PR.

Related discussion:
text: // When specified, it should match one the container or initContainer // names in the pod template. // +optional <del> ContainerName *string `json:"containerName" protobuf:"bytes,1,opt,name=containerName"` </del> <ins> ContainerName *string `json:"containerName,omitempty" protobuf:"bytes,1,opt,name=containerName"` </ins> // Represents the relationship between the container exit code(s) and the // specified values. Containers completed with success (exit code 0) are
Code change:
for a PodFailurePolicyRule. However, when trying to create a JobSet programmatically with a JobTemplate that defines a PodFailurePolicy rule for failing a job immediately if the failed pod had condition DisruptionTarget, I get a validation error indicating that cannot be null. I've tried using both and (with matching versions for package as well). Error: JobSet spec: JobTemplate passes validation. JobSet: applying example JobSet in the description of this issue. JobSet: and applying example JobSet in the description of this issue. No response 30 (tests on a kind cluster using kindest/node:v1.30.0) <details</details<details</details<details</details<details</details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc
/assign
I confirmed the issue, moreover, I see that when the JobSet webhook is disabled then it works ok, I think it must be the JobSet webhook which adds the "onExitCodes" field during deserializion /serialization step. I can also see that when I rebuild JobSet using kubernetes field "onExitCodes" with "omitempty", then it the JobSet creates ok. I will open a PR.

Related discussion:
text: // Represents the requirement on the container exit codes. // +optional <del> OnExitCodes *PodFailurePolicyOnExitCodesRequirement `json:"onExitCodes" protobuf:"bytes,2,opt,name=onExitCodes"` </del> <ins> OnExitCodes *PodFailurePolicyOnExitCodesRequirement `json:"onExitCodes,omitempty" protobuf:"bytes,2,opt,name=onExitCodes"` </ins> // 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 // +optional <del> OnPodConditions []PodFailurePolicyOnPodConditionsPattern `json:"onPodConditions" protobuf:"bytes,3,opt,name=onPodConditions"` </del> <ins> OnPodConditions []PodFailurePolicyOnPodConditionsPattern `json:"onPodConditions,omitempty" protobuf:"bytes,3,opt,name=onPodConditions"` </ins> } // PodFailurePolicy describes how failed pods influence the backoffLimit.
Code change:
After merged we are seeing the new test in fail since it was turned on be default now (it passed in the PR linked because it didn't have the alpha feature enabled). <br class="Apple-interchange-newline"<!--EndFragment--</body /sig windows /sig node /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
ptal

Related discussion:
text: e2eoutput.TestContainerOutput(ctx, f, "check pod SecurityContext username", pod, 1, []string{"ContainerAdministrator"}) }) <del> ginkgo.It("should ignore SELinux Specific SecurityContext if set", func(ctx context.Context) { </del> <ins> ginkgo.It("should ignore Linux Specific SecurityContext if set", func(ctx context.Context) { </ins> ginkgo.By("Creating a pod with SELinux options") // It is sufficient to show that the pod comes up here. Since we're stripping the SELinux and other linux // security contexts in apiserver and not updating the pod object in the apiserver, we cannot validate the
Code change:
After merged we are seeing the new test in fail since it was turned on be default now (it passed in the PR linked because it didn't have the alpha feature enabled). <br class="Apple-interchange-newline"<!--EndFragment--</body /sig windows /sig node /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
ptal

Related discussion:
text: f.Namespace.Name), "failed to wait for pod %s to be running", windowsPodWithSELinux.Name) }) <del> ginkgo.It("should ignore ProcMount Specific SecurityContext if set", func(ctx context.Context) { ginkgo.By("Creating a pod with ProcMount options") // It is sufficient to show that the pod comes up here. Since we're stripping the SELinux and other linux // security contexts in apiserver and not updating the pod object in the apiserver, we cannot validate the // pod object to not have those security contexts. However the pod coming to running state is a sufficient // enough condition for us to validate since prior to https://github.com/kubernetes/kubernetes/pull/93475 // the pod would have failed to come up. windowsPodWithSELinux := createTestPod(f, imageutils.GetE2EImage(imageutils.Agnhost), windowsOS) windowsPodWithSELinux.Spec.Containers[0].Args = []string{"test-webserver-with-selinux"} windowsPodWithSELinux.Spec.SecurityContext = &v1.PodSecurityContext{} pmt := v1.UnmaskedProcMount containerUserName := "ContainerAdministrator" windowsPodWithSELinux.Spec.Containers[0].SecurityContext = &v1.SecurityContext{ ProcMount:      &pmt, WindowsOptions: &v1.WindowsSecurityContextOptions{RunAsUserName: &containerUserName}} windowsPodWithSELinux.Spec.Tolerations = []v1.Toleration{{Key: "os", Value: "Windows"}} windowsPodWithSELinux, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(ctx, windowsPodWithSELinux, metav1.CreateOptions{}) framework.ExpectNoError(err) framework.Logf("Created pod %v", windowsPodWithSELinux) framework.ExpectNoError(e2epod.WaitForPodNameRunningInNamespace(ctx, f.ClientSet, windowsPodWithSELinux.Name, f.Namespace.Name), "failed to wait for pod %s to be running", windowsPodWithSELinux.Name) }) </del> ginkgo.It("should not be able to create pods with containers running as ContainerAdministrator when runAsNonRoot is true", func(ctx context.Context) { ginkgo.By("Creating a pod")
Code change:
July 24th. I think there is some suble way the test is named. Test is covered by and that works. I think this is mainly an issue where this test should not be run with these jobs. /sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
what is the correct way to label a job now? This is apparently wrong and causing the job to be picked up in the unlabeled name.
You still need to have a corresponding feature in because, as you noticed, there are jobs which don't support skipping based on the feature gate.
I created an issue in test-infra. once all tasks are completed, it's okay only to use framework.WithFeatureGate. There may be a lot of jobs that need to be updated. for now, you have to add a feature label or modify all the failing jobs.
/assign
xref

Related discussion:
text: // TODO: document the feature (owning SIG, when to use this feature for a test) PodResources = framework.WithNodeFeature(framework.ValidNodeFeatures.Add("PodResources")) <ins> // ResourceHealthStatus (SIG-node, resource health Status for device plugins and DRA <https://kep.k8s.io/4680>) ResourceHealthStatus = framework.WithNodeFeature(framework.ValidNodeFeatures.Add("ResourceHealthStatus")) </ins> // TODO: document the feature (owning SIG, when to use this feature for a test) ProcMountType = framework.WithNodeFeature(framework.ValidNodeFeatures.Add("ProcMountType"))
Code change:
July 24th. I think there is some suble way the test is named. Test is covered by and that works. I think this is mainly an issue where this test should not be run with these jobs. /sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
what is the correct way to label a job now? This is apparently wrong and causing the job to be picked up in the unlabeled name.
You still need to have a corresponding feature in because, as you noticed, there are jobs which don't support skipping based on the feature gate.
I created an issue in test-infra. once all tasks are completed, it's okay only to use framework.WithFeatureGate. There may be a lot of jobs that need to be updated. for now, you have to add a feature label or modify all the failing jobs.
/assign
xref

Related discussion:
text: v1 "k8s.io/api/core/v1" kubeletdevicepluginv1beta1 "k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" <ins> "k8s.io/kubernetes/test/e2e/nodefeature" </ins> imageutils "k8s.io/kubernetes/test/utils/image" admissionapi "k8s.io/pod-security-admission/api" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" <del> "k8s.io/kubernetes/pkg/features" </del> "k8s.io/kubernetes/test/e2e/framework" "k8s.io/kubernetes/test/e2e_node/testdeviceplugin" ) <del> var _ = SIGDescribe("Device Plugin Failures Pod Status:", framework.WithFeatureGate(features.ResourceHealthStatus), func() { </del> <ins> var _ = SIGDescribe("Device Plugin Failures Pod Status", nodefeature.ResourceHealthStatus, func() { </ins> f := framework.NewDefaultFramework("device-plugin-failures") f.NamespacePodSecurityLevel = admissionapi.LevelPrivileged