jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Remove the folder in favor of . Why is this needed: With the refactoring from the Netpol validation , the tests from folder are deprecated and duplicated at this point. Action items: tests tests
/area testing /sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /area testing /sig network 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
thank you ... !
/triage accepted

Related discussion:
text: "ingressclass.go", "kube_proxy.go", "loadbalancer.go", <del> "network_policy.go", </del> "network_tiers.go", "networking.go", "networking_perf.go",
Code change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Remove the folder in favor of . Why is this needed: With the refactoring from the Netpol validation , the tests from folder are deprecated and duplicated at this point. Action items: tests tests
/area testing /sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /area testing /sig network 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
thank you ... !
/triage accepted

Related discussion:
text: "//test/e2e/framework/service:go_default_library", "//test/e2e/framework/skipper:go_default_library", "//test/e2e/framework/ssh:go_default_library", <del> "//test/e2e/network/netpol:go_default_library", </del> "//test/e2e/network/scale:go_default_library", "//test/e2e/storage/utils:go_default_library", "//test/utils:go_default_library",
Code change:
is a very useful option in scheduler perf test framework to define an operation without waiting for it to finish. However, the current testing logic still waits for all the pods in this operation to be schedulable, in the last step: the number for Pods in this operation to be schedulable This can be problematic as some case just want to generate Pods (for example, to test internal queuing or sorting behavior/latency). The following test command times out as those large-cpu Pods are expected to not fit on any node: So, given is commented as: I'm proposing to relax the semantics to not wait for the Pods to be schedulable if the operation is specified as . /sig scheduling
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
/assign WDYT?

Related discussion:
text: // barrierOp defines an op that can be used to wait until all scheduled pods of // one or many namespaces have been bound to nodes. This is useful when pods <del> // were scheduled with SkipWaitToCompletion set to true. A barrierOp is added // at the end of each each workload automatically. </del> <ins> // were scheduled with SkipWaitToCompletion set to true. </ins> type barrierOp struct { // Must be "barrier". Opcode string
Code change:
is a very useful option in scheduler perf test framework to define an operation without waiting for it to finish. However, the current testing logic still waits for all the pods in this operation to be schedulable, in the last step: the number for Pods in this operation to be schedulable This can be problematic as some case just want to generate Pods (for example, to test internal queuing or sorting behavior/latency). The following test command times out as those large-cpu Pods are expected to not fit on any node: So, given is commented as: I'm proposing to relax the semantics to not wait for the Pods to be schedulable if the operation is specified as . /sig scheduling
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
/assign WDYT?

Related discussion:
text: b.Fatalf("op %d: invalid op %v", opIndex, concreteOp) } } <del> if err := waitUntilPodsScheduled(ctx, podInformer, b.Name(), nil, numPodsScheduledPerNamespace); err != nil { // Any pending pods must be scheduled before this test can be considered to // be complete. b.Fatal(err) } </del> <ins> // Some tests have unschedulable pods. Do not add an implicit barrier at the // end as we do not want to wait for them. </ins> return dataItems }
Code change:
What happened: Sweeping uses of extensions/v1beta1 in preparation for , the addon manager stood out as using extensions/v1beta1 Ingress by default: What you expected to happen: All components shipped in 1.21 must use Ingress in order to work properly against a 1.22 API server. /sig networking cc per cluster/addons/addon-manager/OWNERS cc I'm not sure what the addon manager does if given a prune list of Ingress objects while still using a manifest containing extensions/v1 Ingress objects... this needs to be tested. /milestone v1.21 /priority important-soon /lifecycle frozen
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: cc /priority important-soon /lifecycle frozen 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
/sig network
/triage accepted
how "urgent" is this? Can wait until next tuesday? Otherwise I can work on the tests this weekend :)
important, not urgent. it should happen early in the 1.21 cycle, but does not require work out of business hours
Hello! I am from the Bug Triage team! This issue has not been updated for a few weeks, so I'd like to check on the status. Code freeze is starting March 9th, 2021 (about 1 week from now). We want to ensure that each PR has a chance to be merged before code freeze. As the Issue is tagged for 1.21, is it still planned for this release?
we're waiting to the PR to get merged :) I guess it's important for the v1.21 release, for the sake of extensions apiGroup deprecation :) Will ping reviewers on the PR

Related discussion:
text: apps/v1/Deployment apps/v1/ReplicaSet apps/v1/StatefulSet <del> extensions/v1beta1/Ingress </del> <ins> networking.k8s.io/v1/Ingress </ins> ) else read -ra KUBECTL_PRUNE_WHITELIST <<< "${KUBECTL_PRUNE_WHITELIST_OVERRIDE}"
Code change:
What happened: Sweeping uses of extensions/v1beta1 in preparation for , the addon manager stood out as using extensions/v1beta1 Ingress by default: What you expected to happen: All components shipped in 1.21 must use Ingress in order to work properly against a 1.22 API server. /sig networking cc per cluster/addons/addon-manager/OWNERS cc I'm not sure what the addon manager does if given a prune list of Ingress objects while still using a manifest containing extensions/v1 Ingress objects... this needs to be tested. /milestone v1.21 /priority important-soon /lifecycle frozen
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: cc /priority important-soon /lifecycle frozen 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
/sig network
/triage accepted
how "urgent" is this? Can wait until next tuesday? Otherwise I can work on the tests this weekend :)
important, not urgent. it should happen early in the 1.21 cycle, but does not require work out of business hours
Hello! I am from the Bug Triage team! This issue has not been updated for a few weeks, so I'd like to check on the status. Code freeze is starting March 9th, 2021 (about 1 week from now). We want to ensure that each PR has a chance to be merged before code freeze. As the Issue is tagged for 1.21, is it still planned for this release?
we're waiting to the PR to get merged :) I guess it's important for the v1.21 release, for the sake of extensions apiGroup deprecation :) Will ping reviewers on the PR

Related discussion:
text: func getRESTMappings(mapper meta.RESTMapper, pruneResources *[]pruneResource) (namespaced, nonNamespaced []*meta.RESTMapping, err error) { if len(*pruneResources) == 0 { <del> // default whitelist // TODO: need to handle the older api versions - e.g. v1beta1 jobs. Github issue: #35991 </del> <ins> // default allowlist </ins> *pruneResources = []pruneResource{ {"", "v1", "ConfigMap", true}, {"", "v1", "Endpoints", true},
Code change:
What happened: Sweeping uses of extensions/v1beta1 in preparation for , the addon manager stood out as using extensions/v1beta1 Ingress by default: What you expected to happen: All components shipped in 1.21 must use Ingress in order to work properly against a 1.22 API server. /sig networking cc per cluster/addons/addon-manager/OWNERS cc I'm not sure what the addon manager does if given a prune list of Ingress objects while still using a manifest containing extensions/v1 Ingress objects... this needs to be tested. /milestone v1.21 /priority important-soon /lifecycle frozen
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: cc /priority important-soon /lifecycle frozen 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
/sig network
/triage accepted
how "urgent" is this? Can wait until next tuesday? Otherwise I can work on the tests this weekend :)
important, not urgent. it should happen early in the 1.21 cycle, but does not require work out of business hours
Hello! I am from the Bug Triage team! This issue has not been updated for a few weeks, so I'd like to check on the status. Code freeze is starting March 9th, 2021 (about 1 week from now). We want to ensure that each PR has a chance to be merged before code freeze. As the Issue is tagged for 1.21, is it still planned for this release?
we're waiting to the PR to get merged :) I guess it's important for the v1.21 release, for the sake of extensions apiGroup deprecation :) Will ping reviewers on the PR

Related discussion:
text: {"", "v1", "Service", true}, {"batch", "v1", "Job", true}, {"batch", "v1beta1", "CronJob", true}, <del> {"extensions", "v1beta1", "Ingress", true}, </del> <ins> {"networking.k8s.io", "v1", "Ingress", true}, </ins> {"apps", "v1", "DaemonSet", true}, {"apps", "v1", "Deployment", true}, {"apps", "v1", "ReplicaSet", true},
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --/sig windows /cc After was merged I think.
I agree that looks like the issue. It started failing between the two commits: on this run:
/triage accepted
/assign

Related discussion:
text: PromoterE2eRegistry     string `yaml:"promoterE2eRegistry"` BuildImageRegistry      string `yaml:"buildImageRegistry"` InvalidRegistry         string `yaml:"invalidRegistry"` <del> GcHttpdRegistry         string `yaml:"gcHttpdRegistry"` </del> GcEtcdRegistry          string `yaml:"gcEtcdRegistry"` GcRegistry              string `yaml:"gcRegistry"` SigStorageRegistry      string `yaml:"sigStorageRegistry"`
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --/sig windows /cc After was merged I think.
I agree that looks like the issue. It started failing between the two commits: on this run:
/triage accepted
/assign

Related discussion:
text: BuildImageRegistry:      "k8s.gcr.io/build-image", InvalidRegistry:         "invalid.com/invalid", GcEtcdRegistry:          "k8s.gcr.io", <del> GcHttpdRegistry:         "k8s.gcr.io/e2e-test-images", </del> GcRegistry:              "k8s.gcr.io", SigStorageRegistry:      "k8s.gcr.io/sig-storage", GcrReleaseRegistry:      "gcr.io/gke-release",
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --/sig windows /cc After was merged I think.
I agree that looks like the issue. It started failing between the two commits: on this run:
/triage accepted
/assign

Related discussion:
text: buildImageRegistry      = registry.BuildImageRegistry gcAuthenticatedRegistry = registry.GcAuthenticatedRegistry gcEtcdRegistry          = registry.GcEtcdRegistry <del> gcHttpdRegistry         = registry.GcHttpdRegistry </del> gcRegistry              = registry.GcRegistry sigStorageRegistry      = registry.SigStorageRegistry gcrReleaseRegistry      = registry.GcrReleaseRegistry
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --/sig windows /cc After was merged I think.
I agree that looks like the issue. It started failing between the two commits: on this run:
/triage accepted
/assign

Related discussion:
text: configs[EchoServer] = Config{promoterE2eRegistry, "echoserver", "2.3"} configs[Etcd] = Config{gcEtcdRegistry, "etcd", "3.4.13-0"} configs[GlusterDynamicProvisioner] = Config{promoterE2eRegistry, "glusterdynamic-provisioner", "v1.0"} <del> configs[Httpd] = Config{gcHttpdRegistry, "httpd", "2.4.38-alpine"} configs[HttpdNew] = Config{gcHttpdRegistry, "httpd", "2.4.39-alpine"} </del> <ins> configs[Httpd] = Config{promoterE2eRegistry, "httpd", "2.4.38-1"} configs[HttpdNew] = Config{promoterE2eRegistry, "httpd", "2.4.39-1"} </ins> configs[InvalidRegistryImage] = Config{invalidRegistry, "alpine", "3.1"} configs[IpcUtils] = Config{promoterE2eRegistry, "ipc-utils", "1.2"} configs[JessieDnsutils] = Config{promoterE2eRegistry, "jessie-dnsutils", "1.4"} configs[Kitten] = Config{promoterE2eRegistry, "kitten", "1.4"} configs[Nautilus] = Config{promoterE2eRegistry, "nautilus", "1.4"} configs[NFSProvisioner] = Config{sigStorageRegistry, "nfs-provisioner", "v2.2.2"} <del> configs[Nginx] = Config{promoterE2eRegistry, "nginx", "1.14-alpine"} configs[NginxNew] = Config{promoterE2eRegistry, "nginx", "1.15-alpine"} </del> <ins> configs[Nginx] = Config{promoterE2eRegistry, "nginx", "1.14-1"} configs[NginxNew] = Config{promoterE2eRegistry, "nginx", "1.15-1"} </ins> configs[NodePerfNpbEp] = Config{promoterE2eRegistry, "node-perf/npb-ep", "1.1"} configs[NodePerfNpbIs] = Config{promoterE2eRegistry, "node-perf/npb-is", "1.1"} configs[NodePerfTfWideDeep] = Config{promoterE2eRegistry, "node-perf/tf-wide-deep", "1.1"}
Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --kube-up tries to add metadata to the wrong project. It is trying to add metadata to the prow project running the tests instead of the target project. This is because is missing a kube-up uses the target project to add metadata Don't set/set a different default project and run cluster/kube-up. originally in kubetest hides the project acquired from boskos under the covers by setting it as the default project uncovered as part of migration to kubetest2 xref: /cc
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

Related discussion:
text: get-kubeconfig-basicauth if [[ ${GCE_UPLOAD_KUBCONFIG_TO_MASTER_METADATA:-} == "true" ]]; then <del> gcloud compute instances add-metadata "${MASTER_NAME}" --zone="${ZONE}"  --metadata-from-file="kubeconfig=${KUBECONFIG}" || true </del> <ins> gcloud compute instances add-metadata "${MASTER_NAME}" --project="${PROJECT}" --zone="${ZONE}"  --metadata-from-file="kubeconfig=${KUBECONFIG}" || true </ins> fi echo
Code change:
The method doesn't check taints and tolerations. This is problematic in 2 scenarios: If the users bypass scheduler by setting a value in If the node restarts. The node would try to restart scheduled pods once it comes back up, even if it's not ready (has a not-ready taint). Kubelet to check taints and tolerations. a taint in a node. a Pod with set to the Node above, without a matching toleration. /sig node /sig scheduling
this reminds me of your kubelet sync PR ...
I don't think this is a syncing issue. The logic doesn't check taints at all.
scenario 1 is pretty bad, i will let the #sig-node slack know about this.
It doesn't sound like a syncing issue, but we seem to have multiple issues with pod admission/management on restart currently
I'm aware of that issue. This should be unrelated.
I would like to address this. /assign
I think it would be great to proceed after merging ref:
Please add me as reviewer
/triage accepted
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale PR in review:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

Related discussion:
text: "runtime" v1 "k8s.io/api/core/v1" <ins> "k8s.io/component-helpers/scheduling/corev1" </ins> "k8s.io/klog/v2" v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper" <ins> "k8s.io/kubernetes/pkg/kubelet/types" </ins> "k8s.io/kubernetes/pkg/scheduler" schedulerframework "k8s.io/kubernetes/pkg/scheduler/framework" <ins> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/tainttoleration" </ins> ) type getNodeAnyWayFuncType func() (*v1.Node, error)
Code change:
The method doesn't check taints and tolerations. This is problematic in 2 scenarios: If the users bypass scheduler by setting a value in If the node restarts. The node would try to restart scheduled pods once it comes back up, even if it's not ready (has a not-ready taint). Kubelet to check taints and tolerations. a taint in a node. a Pod with set to the Node above, without a matching toleration. /sig node /sig scheduling
this reminds me of your kubelet sync PR ...
I don't think this is a syncing issue. The logic doesn't check taints at all.
scenario 1 is pretty bad, i will let the #sig-node slack know about this.
It doesn't sound like a syncing issue, but we seem to have multiple issues with pod admission/management on restart currently
I'm aware of that issue. This should be unrelated.
I would like to address this. /assign
I think it would be great to proceed after merging ref:
Please add me as reviewer
/triage accepted
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale PR in review:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale

Related discussion:
text: reasons = append(reasons, &PredicateFailureError{r.Name, r.Reason}) } } <ins> // Check taint/toleration except for static pods if !types.IsStaticPod(pod) { _, isUntolerated := corev1.FindMatchingUntoleratedTaint(nodeInfo.Node().Spec.Taints, pod.Spec.Tolerations, func(t *v1.Taint) bool { // Kubelet is only interested in the NoExecute taint. return t.Effect == v1.TaintEffectNoExecute }) if isUntolerated { reasons = append(reasons, &PredicateFailureError{tainttoleration.Name, tainttoleration.ErrReasonNotMatch}) } } </ins> return reasons }