jiebi/CodeConvo huggingface dataset:
Change:
testCannotConnect(f, f.Namespace, "client-cannot-connect", service, 80) }) <ins> ginkgo.It("should support a 'default-deny-all' policy [Feature:NetworkPolicy]", func() { nsA := f.Namespace nsBName := f.BaseName + "-b" nsB, err := f.CreateNamespace(nsBName, map[string]string{ "ns-name": nsBName, }) framework.ExpectNoError(err, "Error occurred while creating namespace-b.") ginkgo.By("Creating a simple server in another namespace that serves on port 80 and 81.") podB, serviceB := createServerPodAndService(f, nsB, "pod-b", []int{80, 81}) ginkgo.By("Waiting for pod ready", func() { err := e2epod.WaitTimeoutForPodReadyInNamespace(f.ClientSet, podB.Name, nsB.Name, framework.PodStartTimeout) framework.ExpectNoError(err) }) ginkgo.By("Creating client-a, which should be able to contact the server in another namespace.", func() { testCanConnect(f, nsA, "client-a", serviceB, 80) }) policy := &networkingv1.NetworkPolicy{ ObjectMeta: metav1.ObjectMeta{ Name: "default-deny-all", }, Spec: networkingv1.NetworkPolicySpec{ PodSelector: metav1.LabelSelector{}, PolicyTypes: []networkingv1.PolicyType{networkingv1.PolicyTypeEgress, networkingv1.PolicyTypeIngress}, Ingress:     []networkingv1.NetworkPolicyIngressRule{}, Egress:      []networkingv1.NetworkPolicyEgressRule{}, }, } policy, err = f.ClientSet.NetworkingV1().NetworkPolicies(f.Namespace.Name).Create(context.TODO(), policy, metav1.CreateOptions{}) framework.ExpectNoError(err) defer cleanupNetworkPolicy(f, policy) ginkgo.By("Creating client-to-a, which should not be able to contact the server in the same namespace, Ingress check.", func() { testCannotConnect(f, nsA, "client-to-a", service, 80) }) ginkgo.By("Creating client-to-b, which should not be able to contact the server in another namespace, Egress check.", func() { testCannotConnect(f, nsA, "client-to-b", serviceB, 80) }) }) </ins> ginkgo.It("should enforce policy to allow traffic from pods within server namespace based on PodSelector [Feature:NetworkPolicy]", func() { nsA := f.Namespace nsBName := f.BaseName + "-b"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We are missing a test which specifies Ingress,Egress (both) for network policys (in ). Why is this needed: So that our network policy test coverage matches the semantics of what is commented and supported in the API.
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
/assign
/assign I'd like to do this if you don't mind
Sure go ahead. I hadn't gotten to it for a while. Appreciate you picking this up
Change:
return } if !isHostNetwork { <del> teardownNetworkResult := kubecontainer.NewSyncResult(kubecontainer.TeardownNetwork, pod.UID) </del> <ins> teardownNetworkResult := kubecontainer.NewSyncResult(kubecontainer.TeardownNetwork, runningPod.ID) </ins> result.AddSyncResult(teardownNetworkResult) // Tear down network plugin with sandbox id if err := m.networkPlugin.TearDownPod(runningPod.Namespace, runningPod.Name, kubecontainer.ContainerID{ Type: m.runtimeName, ID:   sandboxID, }); err != nil { <del> message := fmt.Sprintf("Failed to teardown network for pod %q using network plugins %q: %v", format.Pod(pod), m.networkPlugin.Name(), err) </del> <ins> message := fmt.Sprintf("Failed to teardown network for pod %s_%s(%s) using network plugins %q: %v", runningPod.Name, runningPod.Namespace, runningPod.ID, m.networkPlugin.Name(), err) </ins> teardownNetworkResult.Fail(kubecontainer.ErrTeardownNetwork, message) glog.Error(message) }

Discussion:
The comment states that the , but the function . /cc
At least currently, is only used for printing, we can change the code to use . :)
+1
Change:
"", // Default fsType ), Capabilities: map[testsuites.Capability]bool{ <del> testsuites.CapPersistence: true, testsuites.CapMultiPODs:   true, </del> <ins> testsuites.CapPersistence:      true, testsuites.CapMultiPODs:        true, testsuites.CapSingleNodeVolume: true, </ins> }, }, }

Discussion:
What happened: When we run csi hostpath driver e2e tests on a multi-node cluster some tests failed because they assume that volumes are node independent but this is not the case for some drivers like hostpath. Related PR; What you expected to happen: Skip the tests that assume volumes are node independent for the drivers that don't support node independent volumes. /sig storage /assign
Change:
return } m.configuration.Store(mergeMutatingWebhookConfigurations(configurations)) <ins> m.initialConfigurationSynced.Store(true) </ins> } func mergeMutatingWebhookConfigurations(configurations []*v1.MutatingWebhookConfiguration) []webhook.WebhookAccessor {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: Instructions 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
Change:
UnavailableReplicas: 0, }, <del> msg:  "Waiting for rollout to finish: 1 old replicas are pending termination...n", </del> <ins> msg:  "Waiting for deployment "foo" rollout to finish: 1 old replicas are pending termination...n", </ins> done: false, }, {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: In our CI, we run multiple times in parallel when we update multiple deployments. This lets us see the status of all deployments as they run. When a deployment succeeds, the final message tells us the name of the deployment. However, the intermediate "Waiting for rollout to finish" messages do not say the name of the deployment. This means that in order to look at multiple rollouts in parallel, we need to manually pipe through another command to prefix it with the rollout name. What you expected to happen: Each line to mention the rollout name. How to reproduce it (as minimally and precisely as possible): Update any deployment, run , note that intermediate status names don't contain the deployment name. Anything else we need to know?: Arguably another fix would be to allow you to pass multiple rollouts to and have kubectl handle polling multiple deployments in parallel. Environment: This is still true on master by code inspection.
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions 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
Change:
w.Write(LEVEL_0, "nSettings:n") w.Write(LEVEL_1, "Allow Privileged:t%tn", psp.Spec.Privileged) <del> w.Write(LEVEL_1, "Allow Privilege Escalation:t%vn", psp.Spec.AllowPrivilegeEscalation) </del> <ins> if psp.Spec.AllowPrivilegeEscalation != nil { w.Write(LEVEL_1, "Allow Privilege Escalation:t%tn", *psp.Spec.AllowPrivilegeEscalation) } else { w.Write(LEVEL_1, "Allow Privilege Escalation:t<unset>n") } </ins> w.Write(LEVEL_1, "Default Add Capabilities:t%vn", capsToString(psp.Spec.DefaultAddCapabilities)) w.Write(LEVEL_1, "Required Drop Capabilities:t%sn", capsToString(psp.Spec.RequiredDropCapabilities)) w.Write(LEVEL_1, "Allowed Capabilities:t%sn", capsToString(psp.Spec.AllowedCapabilities))

Discussion:
What happened: When doing , the Allow Privileged Escalation output shows a hex-encoded value instead of a stringified boolean: What you expected to happen: Show the stringified boolean value instead. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Solution turned out to be simple. Change this line: to be instead of .
/sig cli
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
This was fixed with
Change:
} } <del> // Paranoia-- prevent reuse! </del> <ins> // Unsetting this is relevant for a following test that uses // the same instance because it might not reach f.BeforeEach // when some other BeforeEach skips the test first. </ins> f.Namespace = nil f.clientConfig = nil f.ClientSet = nil

Discussion:
After merged, build logs for e2e tests have started showing stack traces that look like: It seems like the used in this is nil I have a suspicion this is happening for storage tests that skip No new stack traces in build logs Run e2e tests against the in-development version of kubernetes I identified when this started happening by looking for an increase in build-log size is the first build where this started happening, which happens to be the first build after merged, which is the PR that introduced this new way of invoking <details</details<details</details<details</details<details</details<details</details<details</details
/sig testing /triage accepted /assign To put this on your radar
/cc
Correct. This happens because of the ordering in Tests gets skipped before is called. This avoids the expensive namespace creation/deletion for tests that don't need to run. The for then gets executed although the framework didn't get initialized. My preferred solution is to document that the framework instance might not be initialized in an AfterEach callback and add a nil check to .
See Only was affected. The other framework extensions use DeferCleanup, which only runs when needed.
Change:
gomega.Expect(log).To(gomega.ContainSubstring("polo")) }) <del> ginkgo.It("should update the ephemeral containers in an existing pod", func(ctx context.Context) { </del> <ins> /* Release: v1.28 Testname: Ephemeral Container, update ephemeral containers Description: Adding an ephemeral container to pod.spec MUST result in the container running. There MUST now be only one ephermal container found. Updating the pod with another ephemeral container MUST succeed. There MUST now be two ephermal containers found. */ framework.ConformanceIt("should update the ephemeral containers in an existing pod", func(ctx context.Context) { </ins> ginkgo.By("creating a target pod") pod := podClient.CreateSync(ctx, &v1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "ephemeral-containers-target-pod"},

Discussion:
[x] test approval issue : [x] test pr : 18 May 2023 [x] two weeks soak end date : 01 June 2023 [x] test promotion pr : According to following APIsnoop query, there are still 2 PodEphemeralcontainers endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 2 endpoints. The e2e logs for this test are listed below. This query shows the following podephemeralcontainers endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted cc
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions 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
Change:
err = dsc.podControl.CreatePodsWithControllerRef(ds.Namespace, podTemplate, ds, metav1.NewControllerRef(ds, controllerKind)) } else { <ins> // If pod is scheduled by DaemonSetController, set its '.spec.scheduleName'. podTemplate.Spec.SchedulerName = "kubernetes.io/daemonset-controller" </ins> err = dsc.podControl.CreatePodsOnNode(nodesNeedingDaemonPods[ix], ds.Namespace, podTemplate, ds, metav1.NewControllerRef(ds, controllerKind)) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Create a DaemonSet. It'll create pods with schedulerName=default-scheduler. However, the DaemonSet pods aren't actually scheduled by default-scheduler but DaemonSet controller.
If the "schedulerName" is empty, apiserver will set the default value to "default-scheduler". To avoid the confusion, I think we can let DaemonSet set this field (for example 'ds-controller') when creating the DaemonSet pods, WDYT?
What's "schdulerName" for? Is it just for telling the users who scheduled this pod, or is this information used by other resources in the system? Also, I'd expect this field to be set by schedulers. Why is it not set by default scheduler, but apiserver? How does apiserver know which scheduler does the work, if there are more than one? Letting DaemonSet controller set this field sounds reasonable, as DaemonSet controller is the "scheduler".
is introduced by multi-scheduler; a common case is to set it by user in : it means this Pod should be scheduled by specific scheduler. In each scheduler (including the default scheduler), it will check whether it's responsible for the pending Pod. The default value is default scheduler :) Sure, I'll open a PR for this :)
/assign
Isn't scheduler name ignored when spec.nodeName is set?
no, right now; that makes sense, I'll also include this in PR :)
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity.

Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
previousResourceVersion := make(map[string]float64) transport := http.DefaultTransport <del> token := tokenID + "." + secret </del> <ins> token := validTokenID + "." + validSecret </ins> var bodyStr string if test.request.body != "" { sub := ""

Discussion:
Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.
Change:
metrics.PodScheduleError(prof.Name, metrics.SinceInSeconds(start)) // trigger un-reserve plugins to clean up state associated with the reserved Pod prof.RunReservePluginsUnreserve(bindingCycleCtx, state, assumedPod, scheduleResult.SuggestedHost) <ins> if err := sched.SchedulerCache.ForgetPod(assumedPod); err != nil { klog.Errorf("scheduler cache ForgetPod failed: %v", err) } </ins> sched.recordSchedulingFailure(prof, assumedPodInfo, fmt.Errorf("Binding rejected: %v", err), SchedulerError, "") } else { // Calculating nodeResourceString can be heavy. Avoid it if klog verbosity is below 2.

Discussion:
This is a bug found in The scheduler fails to schedule the pod on the first try due to PV is out of sync. This may happen because the PV/PVC may be modified before the scheduler binder assumes them. However, the scheduler skips the pod update event and never try to scheduler the pod again: This is because when the reserve plugins fails, we didn't try to forget the pod. After the is called, the pod is in the state.
/sig scheduling /sig storage /assign /priority critical-urgent
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig scheduling /sig storage /assign /priority critical-urgent Instructions 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
Change:
cmd := fmt.Sprintf(`curl -s -o /dev/null -w "%%{http_code}" --connect-timeout 5 http://%s/healthz`, healthCheckNodePortAddr) out, err := e2eoutput.RunHostCmd(pausePod0.Namespace, pausePod0.Name, cmd) if err != nil { <del> return false, err </del> <ins> framework.Logf("unexpected error trying to connect to nodeport %d : %v", healthCheckNodePortAddr, err) return false, nil </ins> } expectedOut := "200" if out != expectedOut { <ins> framework.Logf("expected output: %s , got %s", expectedOut, out) </ins> return false, nil } return true, nil

Discussion:
pull-kubernetes-e2e-gce, assorted GCE jobs Seems to be elevated today No response No response_ /sig network
three instances:
/assign I've seen it too
/triage accepted
confirmed that it has been fixed !
Change:
return } v.configuration.Store(mergeValidatingWebhookConfigurations(configurations)) <ins> v.initialConfigurationSynced.Store(true) </ins> } func mergeValidatingWebhookConfigurations(configurations []*v1.ValidatingWebhookConfiguration) []webhook.WebhookAccessor {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: Instructions 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
Change:
expected: setPrivHC, }, { <ins> name:     "container.SecurityContext.NoPrivileges", sc:       unsetPrivSC, expected: unsetPrivHC, }, { </ins> name: "container.SecurityContext.Capabilities", sc: &runtimeapi.LinuxContainerSecurityContext{ Capabilities: inputCapabilities(),

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: kind bug What happened: After execute kubeadm init during kube-proxy pod initialization there is CrashLoopBackOff error all the time Logs from pod: [centos ~]$ kubectl logs kube-proxy-8gs45 -n kube-system What you expected to happen: kube-proxy pod run properly How to reproduce it (as minimally and precisely as possible): follow instruction: try to execute: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others:
/sig network
I have exactly the same problem with the 1.12.0-beta.1. Does kube-proxy really need access to /proc/sys/* in this case?
Same problem with Ubuntu
Does that mean kube-proxy can only be run outside of container?
/sig cluster-lifecycle
/milestone v1.12
Looks like docker inspect shows masked and read-only paths (looking at ) even when the pod is
It being close to release, since this is not urgent, please save this for 1.13! /milestone clear /milestone v1.13
/milestone v1.13
/priority critical-urgent /milestone v1.12 Sorry the activity and urgency is reflected in the PR :)
welp! sorry about that!
I'm still seeing this on RC1, did this land before the release was cut? /cc
update from :
I just verified on release-1.12 branch and it's good.