jiebi/CodeConvo huggingface dataset:
Code change:
SSLContext ctx = SSLContext.getInstance("SSL"); ctx.init(null, trustAll, new SecureRandom()); <del> URL url = new URL(host + path + serviceName); </del> <ins> URL url = new URL(proto + host + ":" + port + path + serviceName); </ins> logger.info("Getting endpoints from " + url); HttpsURLConnection conn = (HttpsURLConnection)url.openConnection();

Related discussion:
text: What would you like to be : There is a tab in the k8s perf dashaboard for the scheduler perf benchmarks, but it is showing nothing, we should fix that: http://perf- What this dashboard should be showing is multiple runs per day of We can run it every hour, and summarize the 24 runs of each day to show 50%, 90% and 99% percentile. Why is this needed: Having daily runs of the benchmarks is important to track performance regressions. /sig scheduling /assign /priority important-soon
Ref
/cc
The ci job's config is at And one of failed logs could be found at I tried to reproduce it on my local machine(because I do not have Gloud credentials, I run the task directly in the container): However it works well on my local machine. It is so weird. It will be very appreciated if anyone could help reproduce it with Gloud credentials.
can you try and reach out to the test-infra people? ping them on the slack channel perhaps.
yes, I have tried to get help from , he is busy now. I'll try more.
While working on reproducing this in order to file a bug against test-infra folks I think I found a solution. Will send PRs shortly. /assign
/retitle sig-scalability-benchmarks#scheduler fails consistently due to build issues
/sig scalability Testgrid link: https://k8s- Error logs:
A word about the solution, the job uses the deprecated script which is not supported anymore by test-infra oncall / folks. I've rewritten the job definition to use pod utilities and it started working (will require to get merged first).
Thanks
Thanks !
Code change:
while true; do if result=$(gcloud compute ${resource} list --project=${PROJECT} ${@:2}); then if [[ ! -z "${GREP_REGEX}" ]]; then <del> result=$(echo "${result}" | grep "${GREP_REGEX}") </del> <ins> result=$(echo "${result}" | grep "${GREP_REGEX}" || true) </ins> fi echo "${result}" return

Related discussion:
text: The last 4 runs of https://k8s- have failed on the and steps with : https://k8s- https://k8s- https://k8s- https://k8s- The GCE version of this test suite appears to be fine. This is blocking the submit queue. CC
Is there a way to see what does /cluster/gce/list- output in the runs... exit status 1 is not very informative
Here is a non-gke failure: https://k8s-
Given that the last thing output from the listing of resource is: I would bet that the defined is failing to find a match from (see )
Hummm I ran it locally against but did not get the same failure
you might be more familiar with list-
This started happening on the 16th and became more regular on the 18th-- do you think the new janitor code might be causing this? More details here:
is giving me exit status 1, let me find which command it is.
Yeah, and have figured it out. Because of the janitor, we no longer have any default firewall rules in these projects (which might be a bug), and so now the is failing. I think in the distant past always printed out a header, even if nothing was found, though it hasn't done that in a long time. Fix for is to the on L52. We may also want to decide if we should be deleting the default firewalls.
We'll want to cherrypick that to the old branches, too.
hummm I'll let it skip default-firewall
Keeping open until we've verified fix
Code change:
} // Filter based on extender implemented predicate functions. The filtered list is <del> // expected to be a subset of the supplied list. failedNodesMap optionally contains // the list of failed nodes and failure reasons. </del> <ins> // expected to be a subset of the supplied list; otherwise the function returns an error. // failedNodesMap optionally contains the list of failed nodes and failure reasons. </ins> func (h *HTTPExtender) Filter( pod *v1.Pod, nodes []*v1.Node, nodeNameToInfo map[string]*schedulernodeinfo.NodeInfo,

Related discussion:
text: <!-- 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 --What happened: Default scheduler crash if scheduler extender filter returns a not found node What you expected to happen: Default scheduler just should consider the not found node as not an candidate, instead of crash itself (panic). How to reproduce it (as minimally and precisely as possible): cluster only have 1 node: 0.0.0.1 scheduler extender (with nodeCacheCapable enabled) filter accidentally returns a candidate node: 0.0.0.2 scheduler recieved the candidate nodes: 0.0.0.2 from scheduler extender, but got below error: The is SuggestedHost: filteredNodes[0].Name: Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig scheduling
Code change:
// IsNotMountPoint determines if a directory is a mountpoint. func (mounter *Mounter) IsNotMountPoint(dir string) (bool, error) { <del> return IsNotMountPoint(mounter, dir) </del> <ins> return isNotMountPoint(mounter, dir) </ins> } // IsLikelyNotMountPoint determines if a directory is not a mountpoint.

Related discussion:
text: <!-- 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!--What happened: There's , and . The former is used by local and nfs volume plugins, while the latter is used by , which is also used by local and nfs volume plugins. What you expected to happen: Can we consolidate these? This is really confusing and could easily be the source of bugs. <!-- DO NOT EDIT BELOW THIS LINE --/kind cleanup
cc
/assign I'd like to clean up code.
Code change:
kind: Service apiVersion: v1beta1 <del> id: nginxExample </del> <ins> id: nginx-example </ins> # the port that this service should serve on port: 8000 # just like the selector in the replication controller, # but this time it identifies the set of pods to load balance # traffic to. selector: <del> - name: nginx </del> <ins> name: nginx </ins> # the container on each pod to connect to, can be a name # (e.g. 'www') or a number (e.g. 80) containerPort: 80

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: cAdvisor has a option to only collect docker related cgroups. Kubelet stats api now supports allocatable cgroup, /kubepods, for the runtime cgroup and the kubelet cgroup. But with settings, Kubelet stats api can not query pod related cgroups metrics. FYI: What you expected to happen: should be compatible with kubelet stats api.
/cc
/sig node /sig instrumentation
add to cadvisor in A comma-separated list of cgroup path prefix that needs to be collected even docker-only is specified bump cadvisor dep for Kubernetes setting to
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or .
Code change:
kind: Service apiVersion: v1beta1 <del> id: nginxExample </del> <ins> id: nginx-example </ins> # the port that this service should serve on port: 8000 # just like the selector in the replication controller, # but this time it identifies the set of pods to load balance # traffic to. selector: <del> - name: nginx </del> <ins> name: nginx </ins> # the container on each pod to connect to, can be a name # (e.g. 'www') or a number (e.g. 80) containerPort: 80

Related discussion:
text: /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
Code change:
} } <ins> func createSocketFile(socketDir string) (string, error) { testSocketFile := filepath.Join(socketDir, "mt.sock") // Switch to volume path and create the socket file // socket file can not have length of more than 108 character // and hence we must use relative path oldDir, _ := os.Getwd() err := os.Chdir(socketDir) if err != nil { return "", err } defer func() { os.Chdir(oldDir) }() _, socketCreateError := net.Listen("unix", "mt.sock") return testSocketFile, socketCreateError } </ins> func TestFindExistingPrefix(t *testing.T) { defaultPerm := os.FileMode(0750) tests := []struct {

Related discussion:
text: Subpath unix socket tests can flake because of long socket path. On Linux the path limit should be 108 chars or less. /sig storage
Code change:
<del> load("@io_bazel_rules_go//go:def.bzl", "go_library") </del> <ins> load("@io_bazel_rules_go//go:def.bzl", "go_library", "go_test") </ins> go_library( name = "go_default_library",

Related discussion:
text: Solution: I will add one.
/cc
xref
Thanks for sending a PR so quickly!
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code slush, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: If this issue is not resolved or labeled as by Wed, Nov 22 it will be moved out of the v1.9 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
<del> load("@io_bazel_rules_go//go:def.bzl", "go_library") </del> <ins> load("@io_bazel_rules_go//go:def.bzl", "go_library", "go_test") </ins> go_library( name = "go_default_library",

Related discussion:
text: What would you like to be : Once a metric be deprecated, we should update the unit test accordingly if there is any. We need to work out a way for a unit test freely select codebase version, and also should make sure the unit test won't fail in the subsequent release. Why is this needed: Deprecated also needs to be protected. /sig instrumentation /assign
Code change:
(disk.ManagedDisk != nil && diskURI != "" && strings.EqualFold(*disk.ManagedDisk.ID, diskURI)) { // found the disk klog.V(2).Infof("azureDisk - detach disk: name %q uri %q", diskName, diskURI) <del> disks[i].ToBeDetached = to.BoolPtr(true) </del> <ins> if strings.EqualFold(ss.cloud.Environment.Name, "AZURESTACKCLOUD") { disks = append(disks[:i], disks[i+1:]...) } else { disks[i].ToBeDetached = to.BoolPtr(true) } </ins> bFoundDisk = true break }

Related discussion:
text: <!-- 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 --What happened: flag is not supported on Azure Stack, should switch to use original way to remove a disk from data disk list, refer to for more details What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Code change:
REGISTRY ?= gcr.io/kubernetes-e2e-test-images GOARM=7 QEMUVERSION=v2.9.1 <del> GOLANG_VERSION=1.8.3 </del> <ins> GOLANG_VERSION=1.9.1 </ins> export ifndef WHAT

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind feature This is a followup on , but for Go 1.9 We should do the same kind of testing now to possibly catch bugs in either Go or Kubernetes when doing this kind of dependency version bump. Ideally we'd have automated tests against Go tip (), but we don't have that at the moment, so we have to do it kind of manually. We should also decide which k8s version we should target. k8s v1.8 or v1.9? What Go versions have been used so far? Kubernetes v1.7.0 - go1.8.3 Kubernetes v1.6.0 - go1.7.5 Kubernetes v1.5.0 - go1.7.4 Kubernetes v1.4.0 - go1.6.3 Kubernetes v1.3.0 - go1.6.2 Kubernetes v1.2.0 - go1.4.2 Seems like the trend has been to stay on the same Go version for two releases and then bump. That'd mean we'd switch to Go1.9 in k8s v1.9 Everyone happy with that? Or is there any reason for us to go start using go1.9 in k8s v1.8? In any case, we should indeed start testing go1.9 out now... cc
Let me know if you find any bugs
FWIW pretty tight to code-freeze I would prefer punting out a cycle fwiw.
I don't think we're that close to code freeze given that we have 5 (of 8) weeks left in this coding cycle But I'm happy to defer this to v1.9 if others think that. I guess the main reason for a bump would be scalability goals, but I'm not sure we have the need to expand above 5000 (and that Go would be the bottleneck in that case) for v1.8
made the Go benchmarks 9% faster with 15% larger binaries. I'm interested to see how that affects our numbers.
mid-stack inlining was not included in Go 1.9. It made the compiler too slow. It's being targeted to Go 1.10 now instead, after some compiler optimization work.
Oh, thanks for the correction!
Code change:
REGISTRY ?= gcr.io/kubernetes-e2e-test-images GOARM=7 QEMUVERSION=v2.9.1 <del> GOLANG_VERSION=1.8.3 </del> <ins> GOLANG_VERSION=1.9.1 </ins> export ifndef WHAT

Related discussion:
text: Regardless, we need to run the scalability tests against the RC so we can report issues earlier-- the last upgrade was particularly painful because of an HTTP regression that we caught way too late.
yeah. I filed for that now
yeah, my recollection is that the Go releases usually occur too late in our release cadence and end up getting bumped to the next Kubernetes release. (Also we inevitably find something wrong, though testing RCs would help with that. Though I'm not sure anyone has cycles to test RCs and fix all of the issues that do come up.)
Based on our current time frame, it looks like go1.9 support will have to slip to k8s 1.9. is open to dig into and start things testing, but there's a number of things that have to move.. I'll try to document those this time around to help with future go version bumps. So far: bazel build rules needed to be updated to support go1.9 () bazel version possibly needs to be updated? some of our custom bazel rules broke
When done, we should update this:
/priority important-soon
Updating the dependency is blocked pending bazel 0.6.0 - .
Can we upgrade to 0.6.0 now? Does bazel 0.6.0 have multiarch support btw?
We can't update to depend on bazel 0.6.0+ until we can figure out how to support different versions of the bazelbuild and kubekins-e2e images in PR jobs in prow based on what branch is being tested. cc
Noting that we're working on branching jobs, is testing one option here:
[MILESTONENOTIFIER] Milestone Issue Current <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality.
Code change:
REGISTRY ?= gcr.io/kubernetes-e2e-test-images GOARM=7 QEMUVERSION=v2.9.1 <del> GOLANG_VERSION=1.8.3 </del> <ins> GOLANG_VERSION=1.9.1 </ins> export ifndef WHAT

Related discussion:
text: </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
I approved this for v1.9, this is something we definitely want in order to keep up with Go (and for improved performance)
we're starting to use the forked images now /cc this should be more feasible very soon Edit: test-infra jobs have also been using bazel 0.6 (now 0.6.1) / a recent rules_go to soak things a bit
We've identified a failing test as a result of the WIP PR to upgrade the codebase to go1.9: The admission webhook test fails with certificate errors under go1.9.1, but runs successfully under go1.8.3. cc: who wanted to be alerted to potential bugs
- please see for a possible fix
Code change:
// remove all existing c.RemoveStreams(stream0, stream1) <ins> // remove nil stream should not crash c.RemoveStreams(nil) </ins> if len(c.streams) != 0 { t.Fatalf("should not have any streams, has %d", len(c.streams)) }

Related discussion:
text: <!-- 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 --Since upgrading to Kubernetes v1.19.11 (from v1.19.10) we see occasional panics in kubelet related to portforward streams: This issue seem to be introduced with should not panic and crash. We have not been able to successfully force this to happen, but it has happened 41 times in the last 2 weeks across 7 clusters (~100 nodes). Kubernetes version (use ):Cloud provider or hardware configuration: Self managed clusters on AWS. OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig node /cc
Hey thank you for the report! :pray: Uhh, thats unfortunate. The panic occurs there on L101: It looks like because works. The stack trace indicates the same: A on is a no-op, so would not be harmful. does also not seem to be , a crash in would have been visible in the stack trace. It may be possible that something assigned to the stream interface. Which means a check for will return , but accessing its fields is causing a segmentation fault. This does not explain why the crash is not visible in the trace.
With a quick look at the streaming code it's likely to be triggered by a timeout in waiting for streams: If the above case is hit then it goes down to , and if the timeout occurs before then it means that either or And then it attempts to remove the streams where at least one is : So it probably makes sense to check for either before passing to or inside the method where it crashes. This theory lines up with our kubelet logs, where I can see this just before the panic (didn't notice before):
Thank you for the summary working on a fix in
/triage accepted /assign
do you use dockershim within your cluster?
Yes, we still use dockershim.
Good, that's also why the panic happens within the kubelet.
Just to make sure I understand the scope of this issue, this only affects things like or other things that use the API, correct?
Exactly :+1:
Code change:
if _, err := dc.coreClient.CoreV1().Pods(tc.pod.Namespace).Create(ctx, tc.pod, metav1.CreateOptions{}); err != nil { t.Fatalf("Failed to create pod: %v", err) } <ins> dc.clock.Sleep(tc.timePassed) </ins> if err := dc.informerFactory.Core().V1().Pods().Informer().GetIndexer().Add(tc.pod); err != nil { t.Fatalf("Failed adding pod to indexer: %v", err) } <del> dc.clock.Sleep(tc.timePassed) </del> <ins> diff := "" </ins> if err := wait.Poll(100*time.Millisecond, wait.ForeverTestTimeout, func() (bool, error) { <del> return dc.stalePodDisruptionQueue.Len() == 0, nil </del> <ins> pod, err := dc.kubeClient.CoreV1().Pods(tc.pod.Namespace).Get(ctx, tc.pod.Name, metav1.GetOptions{}) if err != nil { t.Fatalf("Failed getting updated pod: %v", err) } diff = cmp.Diff(tc.wantConditions, pod.Status.Conditions, cmpopts.IgnoreFields(v1.PodCondition{}, "LastTransitionTime")) return diff == "", nil </ins> }); err != nil { <del> t.Fatalf("Failed waiting for worker to sync: %v", err) } pod, err := dc.kubeClient.CoreV1().Pods(tc.pod.Namespace).Get(ctx, tc.pod.Name, metav1.GetOptions{}) if err != nil { t.Fatalf("Failed getting updated pod: %v", err) } diff := cmp.Diff(tc.wantConditions, pod.Status.Conditions, cmpopts.IgnoreFields(v1.PodCondition{}, "LastTransitionTime")) if diff != "" { t.Errorf("Obtained pod conditions (-want,+got):n%s", diff) </del> <ins> t.Fatalf("Failed waiting for worker to sync: %v, (-want,+got):n%s", err, diff) </ins> } }) }

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --/kind flake <!-- Please assign a SIG using: /sig SIG-NAME --/sig testing apps
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
can you PTAL, it seems this test was in It doesn't seem to have a high rate of failure , but seems flakes are legit
/assign
side note: it's really hard to make it fail in a fast machine :) I had to temporarily add a sleep in the reconciler.
have you tried Jordan's instructions compiling and running with ? for integration you should have an external etcd instance
I haven't. Good to know for next time :)
Code change:
k8s-app: nvidia-gpu-device-plugin addonmanager.kubernetes.io/mode: Reconcile spec: <ins> selector: matchLabels: k8s-app: nvidia-gpu-device-plugin </ins> template: metadata: labels:

Related discussion:
text: This issue is here to satisfy PR requirements of issue association. A lot of times we need to do version bumps for minor bug fixes that don't deserve a separate issue in the kubernetes/kubernetes repo. /kind bug /sig node
/lifecycle frozen
all the linked PRs are emrged and no activity since more than 3 years /close
Closing this issue. <detailsIn response to : all the linked PRs are emrged and no activity since more than 3 years /close 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