jiebi/CodeConvo huggingface dataset:
Change:
"path/filepath" "regexp" "strings" <ins> "sync" </ins> "time" "github.com/spf13/pflag"

Discussion:
/kind bug What happened: takes ~11 seconds when there are thousands of CRDs and is around 28KiB. logs the following message once per resource: Removing unnecessary entries from reduces the runtime by around ten seconds. What you expected to happen: only parses once, and therefore doesn't run unnecessarily slowly. How to reproduce it (as minimally and precisely as possible): shows the config being loaded multiple times (assuming you have multiple pods in the current cluster). Alternatively, add 10-15 clusters to and create ~3000 of a cheap resource (eg custom resources or empty config maps). Run on this resource and observe that it is unnecessarily slow. Anything else we need to know?: I've created a CPU profile using the latest CI build of kubectl, which shows ~12 seconds being spent in . Environment: Kubernetes version (use ): v1.12.1 (also Cloud provider or hardware configuration: GKE or minikube --vm-driver=none OS (e.g. from /etc/os-release): Debian Buster-like Kernel (e.g. ): 4.17.0
/sig cli
/assign
Same problem here. I have less resources but more contexts in my kubeconfig file. With 90 pods and ~300 contexts in the kubeconfig it also takes ~10 seconds for a simple kubectl get pods Note: I tried it with kubectl: 1.11.0, 1.12. With kubectl 1.10.5 the kubeconfig was loaded only once.
I'm unable to reproduce this as of the latest master. My kubeconfig is only loaded 4 times, no matter how many resources are loaded.
When I try a kubectl v1.13.0-alpha.3 against unfortunately a 1.9.11 Kubernetes Cluster I still have the problem: `
Maybe the bug is Linux-only? Presumably the kubeconfig location is different on different platforms, so maybe it has a different code path. I can repro on latest master:
I filed to fixed this. You can try to help validate it. Thanks.
Works for me, thanks!
Change:
import "fmt" <del> func GetVMUUID() (string, error) { </del> <ins> func getRawUUID() (string, error) { </ins> return "", fmt.Errorf("Retrieving VM UUID on this build is not implemented.") }

Discussion:
<!-- 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: Running the vSphere cloud provider on a windows node throws the following error: This is because the vm identifier is retrieved with the command - , which assumes that the uuid and serial are the same. On some vmware vm versions, the uuid and serial are not the same. vmware (comment), vmware (comment) What you expected to happen: Kubelet is able to find vm in vCenter from the identifier looked up on the node. or should be used instead to find the vm identifier. How to reproduce it (as minimally and precisely as possible): Issue only occurs on some vm versions, such as 13. Anything else we need to know?: On the linux side, this issue was resolved by switching from looking up the id from to . See Some discussion about this issue here - Environment: Kubernetes version (use ): 14.0-beta.1 Cloud provider or hardware configuration: Vsphere OS (e.g: ): Windows 2019 Kernel (e.g. ): Install tools: Others:
/sig windows /sig vmware
/milestone v1.14
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.14 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
/assign
Change:
// in the test anyway. continue } <del> // If the image policy is not PullAlways, the image must be in the white list and </del> <ins> // If the image policy is not PullAlways, the image must be in the pre-pull list and </ins> // pre-pulled. <del> gomega.Expect(ImageWhiteList.Has(c.Image)).To(gomega.BeTrue(), "Image %q is not in the white list, consider adding it to CommonImageWhiteList in test/e2e/common/util.go or NodeImageWhiteList in test/e2e_node/image_list.go", c.Image) // Do not pull images during the tests because the images in white list should have </del> <ins> gomega.Expect(ImageWhiteList.Has(c.Image)).To(gomega.BeTrue(), "Image %q is not in the white list, consider adding it to CommonImageWhiteList in test/e2e/common/util.go or NodePrePullImageList in test/e2e_node/image_list.go", c.Image) // Do not pull images during the tests because the images in pre-pull list should have </ins> // been prepulled. c.ImagePullPolicy = v1.PullNever }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should come up with a better name for : Why is this needed: From /sig testing /priority important-soon /cleanup /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --We should come up with a better name for : From /priority important-soon /cleanup /help /good-first-issue 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
I'd like to help out with this. /assign
mind. It seems like you have a PR for it already. /unassign
And I misread the changes you made in . I'm back on this one. /assign
I'm going to rename this to . Please let me know if there are any objections or if there are things that I should be considering.
please feel free to take it. I'm only changing ImageWhileList withint
ultimately was changed to NodePrePullImageList because that's what it's actually used for, not for any sort of filtering.
Change:
defer rc.CleanUp() hpa := e2eautoscaling.CreateCPUHorizontalPodAutoscalerWithBehavior( <del> rc, int32(targetCPUUtilizationPercent), 1, 5, e2eautoscaling.HPABehaviorWithDownscaleStabilizationSeconds(int32(downScaleStabilization.Seconds())), </del> <ins> rc, int32(targetCPUUtilizationPercent), 1, 5, int32(downScaleStabilization.Seconds()), </ins> ) defer e2eautoscaling.DeleteHPAWithBehavior(rc, hpa.Name)

Discussion:
gce-cos-autoscaling-hpa-cpu Kubernetes e2e suite.[sig-autoscaling] [Feature:HPA] [Serial] [Slow] Horizontal pod autoscaling (non-default behavior) with long upscale stabilization window should scale up only after the stabilization period Since it was in (first run at 2022-06-14 13:13 CEST failed, all subsequent runs failed too). https://k8s- Times out when waiting for scale down (), logs from (): I'm not sure why exactly, I have 2 ideas: It looks like the consumer briefly consumes 440 mCPU, which could result in a higher recommendation being generated HPA stabilises initial size of the consumer Increasing timeout should fix the issue No response_ /sig autoscaling
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
FYI
This was already reverted (and later the test got fixed and merged). /close
Closing this issue. <detailsIn response to : This was already reverted (and later the test got fixed and merged). 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:
} wg.Add(1) go func(index int) { <del> defer wg.Done() </del> <ins> metrics.SchedulerGoroutines.WithLabelValues("prioritizing_mapreduce").Inc() defer func() { metrics.SchedulerGoroutines.WithLabelValues("prioritizing_mapreduce").Dec() wg.Done() }() </ins> if err := priorityConfigs[index].Reduce(pod, meta, nodeNameToInfo, results[index]); err != nil { appendError(err) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign
Change:
"github.com/onsi/ginkgo" "github.com/onsi/gomega" v1 "k8s.io/api/core/v1" <del> rbacv1 "k8s.io/api/rbac/v1" </del> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels"

Discussion:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Last successful run (23 Oct 2020, 10:07 PDT): First unsuccessful run (23 Oct 2020, 12:08 PDT): Testgrid link: Reason for failure: Anything else we need to know: presubmit job in repository also started to fail in the same fashion. Attempted to debug it myself, found out the following stuff: last successful run was accessing the apiserver via HTTP: all unsuccessful runs attempted to access the apiserver via HTTPS but to no avail: perused the history of to find out that the PR is almost certainly the reason of the failures (or rather uncovered some problem with the NPD or its tests): first, it coincides with the start of the failures of , second, we changed the default hostname of the apiserver in node tests in that PR. Judging by the code and the changes in the aforementioned PR I think that a quick mitigation would be to add a flag to the of these jobs. /assign /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
Opened for a mitigation that would make those jobs stop failing.
This won't work, unfortunately. Copying response:
I have filed to address this issue, but it seems I could not run the test in advance to verify my patch, did you know how to manually trigger the presubmit job?
Unfortunately I don't :/. My PR was also a wild guess. could you take a look at the proposed fix? Thanks once again for your help - really appreciated :).
the submission of hasn't fixed the problems, unfortunately :/. Sample failing run: We still have some peculiar problem related to health checking: and now NPD panics, too:
Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. /reopen
Reopened this issue.

<detailsIn response to : Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. 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
filed . I hope we could completely address this issue this time.
/milestone v1.20
Change:
if [[ ${#block_devices[@]} == 0 ]]; then echo "No ephemeral block devices found; will use aufs on root" docker_storage="aufs" <del> # Install aufs kernel module (for ubuntu) apt-get install --yes linux-image-extra-$(uname -r) # Install aufs tools (for debian) apt-get install --yes aufs-tools </del> else echo "Block devices: ${block_devices[@]}"

Discussion:
On AWS with Vivid, auplink is not installed. There are messages in the docker log about auplink not being in the path. Inspection of the format-disks script confirms this to be the case. (PR coming soon, just opening an issue so we have something to track it back to!)
Change:
kubectl get rc,services # List one or more resources by their type and names. <del> kubectl get rc/web service/frontend pods/web-pod-13je7 # List all resources with different types. kubectl get all`)) </del> <ins> kubectl get rc/web service/frontend pods/web-pod-13je7`)) </ins> ) const (

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature /sig cli What happened: I have two custom resources in my cluster called Cluster, and couldn't figure out how to ask for one or the other. was of no help, and various Google searches for things like "kubectl apigroup" or "kubectl crd" revealed nothing of use. Worse, some bugs that came up like suggested that the syntax was , which produced entirely incorrect output (e.g. results in . Eventually, I stumbled by accident on the correct way to do it, which is to do and then , where is the name of the custom resource exactly as listed in the output of . I still don't know how to request a specific API version using this syntax, if that is even possible. What you expected to happen: I expected to document how to query custom resources, given that they're increasingly central to running production quality clusters with various operators. Failing that, I expected the k8s website to have documentation on querying custom resources that is discoverable via Google search. How to reproduce it (as minimally and precisely as possible): Install something that uses custom resources (e.g. Calico in k8s datastore mode, Rook), and try to one of the custom resources by precise name (e.g. assume that there are multiple objects defined by different CRDs, so you can't just , you have to be more precise). Environment: Kubernetes version (use ): 1.10.2 client+cserver
Opened with examples
Change:
Command: []string{ "sh", "-c", <del> "trap "echo SIGTERM caught" SIGTERM SIGINT; touch /tmp/healthy; sleep 1000", </del> <ins> "trap "echo SIGTERM caught" SIGTERM SIGINT; touch /tmp/healthy; /bin/sleep 1000", </ins> }, // Using readiness probe to guarantee signal handler registering finished ReadinessProbe: &v1.Probe{

Discussion:
After is fixed, there are still several failing cases. This one is one of them. /kind failing-test /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
/assign
Super weird, still looking but appears to be segfaulting. but it works fine if I manually run the container with , I've tried both with and without a TTY.
Switching from to eliminated the segfault and the test passes. The binary from the 1.29-4 container works fine on this system outside of the pod, and works fine using a container manually started with . Trying to identify why it fails with 1.29-4 when run from a pod, but not ctr directly. I built a busybox top v1.29 binary with debugging information into a new image to debug further, and no crash.
HUH!!! wow.
Change:
detect-master <del> ./target/cloudcfg -h https://${KUBE_MASTER_IP} $@ </del> <ins> $(dirname $0)/../../target/cloudcfg -h https://${KUBE_MASTER_IP} $@ </ins>

Discussion:
<!-- 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: The image () used to run the per-pod infra/pause container logs to stdout about once per second. What you expected to happen: Pause container not logging anything. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Kubelet does not expose, nor manage these logs. Writing the logs wastes resources and takes up disk space, which may not be properly accounted by kubelet. The pause image used for the e2e tests seems much better: 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:
/assign Will also rebuild with
Change:
link += "http://" + ip + ":" + strconv.Itoa(int(port.Port)) + " " } } else { <ins> name := service.ObjectMeta.Name if len(service.Spec.Ports) > 0 { port := service.Spec.Ports[0] // guess if the scheme is https scheme := "" if port.Name == "https" || port.Port == 443 { scheme = "https" } // format is <scheme>:<service-name>:<service-port-name> name = utilnet.JoinSchemeNamePort(scheme, service.ObjectMeta.Name, port.Name) } </ins> if len(client.GroupVersion.Group) == 0 { <del> link = client.Host + "/api/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + service.ObjectMeta.Name + "/proxy" </del> <ins> link = client.Host + "/api/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + name + "/proxy" </ins> } else { <del> link = client.Host + "/api/" + client.GroupVersion.Group + "/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + service.ObjectMeta.Name + "/proxy" </del> <ins> link = client.Host + "/api/" + client.GroupVersion.Group + "/" + client.GroupVersion.Version + "/namespaces/" + service.ObjectMeta.Namespace + "/services/" + name + "/proxy" </ins> } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kubectl cluster-info displays proxy urls for cluster services If those services are using https, the referenced urls do not work (they try to proxy using http) What you expected to happen: Services with a port name of https or 443 should use the ‘https:<name:<port‘ form 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /assign /sig cli
Change:
}, expected: false, }, <ins> { cfg: &kubeadmapi.MasterConfiguration{ API: kubeadmapi.API{AdvertiseAddress: "2001:1234::1:15"}, }, expected: false, }, </ins> } for _, rt := range tests {

Discussion:
BUG REPORT /kind bug What happened: Kubeadm checks that bridge-nf-call-iptables (IPv4) is set, but does not check for bridge-nf-call-ip6tables (IPv6) What you expected to happen: If IPv6 is being used, then Kubeadm should check for bridge-nf-call-ip6tables How to reproduce it (as minimally and precisely as possible): Just running Kubeadm, however it's only a problem when running IPv6 Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area ipv6 /area kubeadm
/sig network
Change:
detect-master parse-master-env <ins> backfile-kubeletauth-certs </ins> # Delete the master instance. Note that the master-pd is created # with auto-delete=no, so it should not be deleted.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug What happened: Upgrade hangs. API server won't start because it doesn't have valid certs. What you expected to happen: Upgrade succeeds How to reproduce it (as minimally and precisely as possible): Anything else we need to know: https://k8s- is an example. Log from kube- I reproduced this locally and checked the certs: apiserver.{crt,key} are empty.
cc
Looks like this is still failing? https://k8s-
Seems that way.
cc
5, to 1.6
- is this something you are actively looking into? This is blocking all of the GCE upgrade test jobs from running so important to get fixed ASAP. thanks!
As of today I am.
do you have an update on this? Now that the jobs are set up, this is a blocker for 1.6 upgrade testing. Thanks!
I started looking at this yesterday, figured out what was going wrong. The problem is due to enabling RBAC. There are a couple options to fix. I should have a fix prepared and out for review today or tomorrow.
With the I hit another problem. Here is the apiserver error log: Reopen this.
from release-1.5 to master, I am not able to reproduce. verified that this fixed our CI tests.
Sorry, I forgot that my script is upgrade from 1.5.3 to 1.6.0-beta.1, which doesn't include your fix. Will verify again and close this one if it works. :)
Wait, it seems that you only changed , then I'm indeed using the latest to upgrade from v1.5.3 to v1.6.0-beta.1. Is there anything missing in v1.6.0-beta.1?
I think beta.2 rolled up this fix.

master-only upgrades seem to be working correctly now, however full-cluster upgrades aren't getting the cluster into a functioning state: <*errors.errorString | 0xc422c96f10: { I0309 08:45:31.969] s: "failed to get logs from downwardapi-volume--04e7-11e7-986c- for client-container: the server has asked for the client to provide credentials (get pods downwardapi-volume--04e7-11e7-986c-)", See https://k8s-
OK. It works from v1.5.3 to v1.6.0-beta.2. Close this one. :)
looking.... sounds like it might be related :( :(
broke upgrades since it adds a group to certificates that certificates generated with 1.5 don't have. This is causing:
upgrades should still have the existing ABAC policy in place
ahh, ok. I'll look into why that's not helping.
Infinity bugs. PTAL at
can this be closed?
Change:
}, }, { <del> description: "pod specified toleration for taint `unreachable`, expect add toleration for `notReady:NoExecute`", </del> <ins> description: "pod specified toleration for taint `unreachable`, expect add toleration for `not-ready:NoExecute`", </ins> requestedPod: api.Pod{ Spec: api.PodSpec{ Tolerations: []api.Toleration{

Discussion:
<!-- 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?: What happened: When discussing issue in , I noticed: although is using key , it has actually been changed to in for quite a while. I am thinking we may need to fix this inconsistency in 1.9, by moving out of alpha. Anything else we need to know?: Task tracker: [x] update [x] update kubernetes doc
/sig scheduling