jiebi/CodeConvo huggingface dataset:
Code change:
serviceConfig.RegisterEventHandler(s.Proxier) go serviceConfig.Run(wait.NeverStop) <del> if utilfeature.DefaultFeatureGate.Enabled(features.EndpointSlice) { </del> <ins> if s.UseEndpointSlices { </ins> endpointSliceConfig := config.NewEndpointSliceConfig(informerFactory.Discovery().V1beta1().EndpointSlices(), s.ConfigSyncPeriod) endpointSliceConfig.RegisterEventHandler(s.Proxier) go endpointSliceConfig.Run(wait.NeverStop)

Related discussion:
text: After this () has been merged and EnpointSlice feature is now enabled by default, we noticed Kube-proxy will not work on Windows. Only message I can see in the logs is: /sig windows
/cc /cc /cc
How about separating the above check into two if statements so that the log can pinpoint which field is false ?
It seems long term, EndpointSlice support should be so that is kept in sync with other implementations.
cc
Thanks for reporting this! Windows proxiers were still intended to be reading from Endpoints, but apparently that's not working as intended. EndpointSlices are moving back to disabled by default for 1.17, so that should fix the failing tests for now. I'll work on an actual fix for this as well, but it may not make it in until after KubeCon. /assign /sig network /priority important-soon
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
/assign cc
GitHub didn't allow me to assign the following users: jocelynberrendonner. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign cc 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
: Please let me know if you need any help on the fix! I'll be more than happy to review/help test the fix on Windows.
Code change:
annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: <del> addonmanager.kubernetes.io/mode: Reconcile </del> <ins> addonmanager.kubernetes.io/mode: EnsureExists </ins> provisioner: kubernetes.io/host-path

Related discussion:
text: <!-- 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: Not able to change the default storage class. What you expected to happen: Default storage class to change. How to reproduce it (as minimally and precisely as possible): But after few mins. Anything else we need to know?: Tried to remove the annotation but no luck. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: minikube OS (e.g. from /etc/os-release): Buildroot 2018.05 Kernel (e.g. ): 4.16.14 Install tools: minikube Others:
/assign
Those labels are not set on the issue: <detailsIn response to : /remove-sig api-machinery 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 cluster-lifecycle
The cause is that kube-addon-manager is reconciling the standard storage class.
Those labels are not set on the issue: <detailsIn response to : /remove-sig api-machinery 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
Thanks for looking into it. Sorry for native question, I want to keep only ceph as a default storage class how can I do that?
hi I'm not really sure about the actual command to fix this. Basically, you could log into the VM and do the same modification as the PR above does, then restart minikube.
Has the fix made it into minikube yet? I'm still seeing the issue in 0.31.0
Looking at PR , the fix was made in kubernetes core, not minikube. The error still exists in minikube:
Code change:
get(t, "valid TLS cert again", false) } <ins> func TestConcurrentUpdateTransportConfig(t *testing.T) { n := time.Now() now := func() time.Time { return n } env := []string{""} environ := func() []string { s := make([]string, len(env)) copy(s, env) return s } c := api.ExecConfig{ Command:    "./testdata/test-plugin.sh", APIVersion: "client.authentication.k8s.io/v1alpha1", } a, err := newAuthenticator(newCache(), &c) if err != nil { t.Fatal(err) } a.environ = environ a.now = now a.stderr = ioutil.Discard stopCh := make(chan struct{}) defer close(stopCh) numConcurrent := 2 for i := 0; i < numConcurrent; i++ { go func() { for { tc := &transport.Config{} a.UpdateTransportConfig(tc) select { case <-stopCh: return default: continue } } }() } time.Sleep(2 * time.Second) } </ins> // genClientCert generates an x509 certificate for testing. Certificate and key // are returned in PEM encoding. func genClientCert(t *testing.T) ([]byte, []byte) {

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: Data race in client-go with below sample code: Data race: What you expected to happen: No data race How to reproduce it (as minimally and precisely as possible): Using above given sample code Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g: ): OSX
/sig api-machinery
I'd like to take it. /assign
/remove-sig api-machinery /sig auth cli
Bug triage for release 1.17 here. Since this issue has been tagged for the milestone, we would like to check it's status. Code freeze is on Nov. 14. Will this issue be resolved before then?
Another reminder here that code freeze is in less than two weeks (Nov. 14). We will need to move this issue out of the milestone if isn't going to be resolved before then.
Code change:
<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: apps/v1 </ins> kind: DaemonSet metadata: name: nvidia-gpu-device-plugin

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
Code change:
fmt.Fprint(out, "n") } <ins> func printMissingMetricsNodeLine(out io.Writer, nodeName string) { printValue(out, nodeName) unknownMetricsStatus := "<unknown>" for i := 0; i < len(MeasuredResources); i++ { printValue(out, unknownMetricsStatus) printValue(out, "t") printValue(out, unknownMetricsStatus) printValue(out, "t") } fmt.Fprint(out, "n") } </ins> func printValue(out io.Writer, value interface{}) { fmt.Fprintf(out, "%vt", value) }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: kubectl top nodes didn't report one of my nodes. I have a cluster of 8 and only 7 printed.
Code change:
fmt.Fprint(out, "n") } <ins> func printMissingMetricsNodeLine(out io.Writer, nodeName string) { printValue(out, nodeName) unknownMetricsStatus := "<unknown>" for i := 0; i < len(MeasuredResources); i++ { printValue(out, unknownMetricsStatus) printValue(out, "t") printValue(out, unknownMetricsStatus) printValue(out, "t") } fmt.Fprint(out, "n") } </ins> func printValue(out io.Writer, value interface{}) { fmt.Fprintf(out, "%vt", value) }

Related discussion:
text: <pre:::: fang 10:04:02 (cgthayer-pchat) 0 platform; kubectl top nodes NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% gke-charles-test-cluster-default-pool--jkrj 311m 33% 2470Mi 93% gke-charles-test-cluster-default-pool--krsh 154m 16% 1763Mi 66% gke-charles-test-cluster-default-pool--vhgq 265m 28% 1954Mi 73% gke-charles-test-cluster-default-pool--x3bs 186m 19% 1990Mi 75% gke-charles-test-cluster-default-pool--073f 270m 28% 1729Mi 65% gke-charles-test-cluster-default-pool--09zf 403m 42% 2698Mi 102% gke-charles-test-cluster-default-pool--p7h1 191m 20% 1582Mi 59% :::: fang 10:04:07 (cgthayer-pchat) 0 platform; kubectl get nodes NAME STATUS ROLES AGE VERSION gke-charles-test-cluster-default-pool--073f Ready <none7d v1.7.12-gke.1 gke-charles-test-cluster-default-pool--09zf Ready <none7d v1.7.12-gke.1 gke-charles-test-cluster-default-pool--cl65 Ready <none6d v1.7.12-gke.1 gke-charles-test-cluster-default-pool--jkrj Ready <none8d v1.7.12-gke.1 gke-charles-test-cluster-default-pool--krsh Ready <none8d v1.7.12-gke.1 gke-charles-test-cluster-default-pool--p7h1 Ready <none7d v1.7.12-gke.1 gke-charles-test-cluster-default-pool--vhgq Ready <none8d v1.7.12-gke.1 gke-charles-test-cluster-default-pool--x3bs Ready <none8d v1.7.12-gke.1 <preWhat you expected to happen: I expected all nodes to be printed.
Code change:
fmt.Fprint(out, "n") } <ins> func printMissingMetricsNodeLine(out io.Writer, nodeName string) { printValue(out, nodeName) unknownMetricsStatus := "<unknown>" for i := 0; i < len(MeasuredResources); i++ { printValue(out, unknownMetricsStatus) printValue(out, "t") printValue(out, unknownMetricsStatus) printValue(out, "t") } fmt.Fprint(out, "n") } </ins> func printValue(out io.Writer, value interface{}) { fmt.Fprintf(out, "%vt", value) }

Related discussion:
text: Since the missing node might have bad data I might expect it to have the same number of columns with "-" values and a note in a new 6th column saying something like "unavailabe" "unresponsive" "stale-data" etc. e.g. <pregke-charles-test-cluster-default-pool--p7h1 - - - - unreachable </preHow to reproduce it (as minimally and precisely as possible): Not sure. Perhaps run a pod where you can intentionally trigger it to use too much cpu or memory. Anything else we need to know?: Environment: Kubernetes version (use ): kubectl version Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-12-21T06:34:11Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.8-gke.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-16T18:26:58Z", GoVersion:"go1.8.3b4", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli
/kind feature
I raise a PR to print when the metrics is missing. As for the 6th column you mentioned, I think it could be debatable for its necessity. :)
Code change:
import ( "context" <del> "fmt" </del> "math/rand" <del> "strings" </del> "time" v1 "k8s.io/api/core/v1"

Related discussion:
text: The metric used to report acutal pod in the label , but now I see the podname prefix only. The full pod name in the label, so I can trace the metric to the failing pod. Check raw api and verify the actual pod name with uids. <details</detailsAzure AKS <details</detailsNo response No response No response_
/sig node
/triage accepted /priority important-soon /cc As discussed this is a change in functionaloty that wasn't highlighted in release notes. Need to decide on what do do with it. I understand it's a change of functionality. what is the side effect of this for you? Does the label without last part not informational enough?
I've been using the metric in my custom grafana dashboard that shows CPU, RAM, IO usage of pods with graph of increases in probes. If the apps are stable, the probe graph looks steadily. I can see if some irregularities in system metrics are influencing probes of respective pod. Also, if readiness probe is failing, the pod is removed from service, but is not restarted so I must have knowledge of pods with failing readiness probes. I attach the screenshot of my graph. ! So I'd welcome the possibility to pair the probes with exact pod and thank you for looking into it.
are we thinking that this resulted in an undesirable change? Spologies for being a bit late to reply, I'm returning from a brief paternity leave staycation.
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release. You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
Well this is awkward... I still believe the actual behavior does not respect the intended idea...
This issue makes it hard to link probe metrics with right pods. The value of pod label in and are also inconsistent with how it is used in other kubelet metrics, see: vs Definitely a bug, regression since 1.25.
I can't get anyone to look at the fix/revert: you may have better luck
/milestone v1.28
discussion in
You've pushed it through, congrats!
Code change:
// Ensure all of the pods that we found on this node before the reboot are // running / healthy. if !checkPodsRunningReady(c, ns, podNames, rebootPodReadyAgainTimeout) { <ins> newPods := ps.List() printStatusAndLogsForNotReadyPods(c, pods, newPods) </ins> return false }

Related discussion:
text: We are running heapster, dns server, kube-proxy etc. in kube-system namespace. Some e2e tests try to make sure all those kube-system pods are at ready state before firing the real tests, others just simply ingore them. But both cases might cause e2e flakiness when some of those kube-system containers are in crashloop, for example, for heapster crashloop, for influxdb crashloop, etc. When such cases happen, the developer doesn't have much information on why since the nodes might be teared down. We should watch those kube-system pods, and onContainerFailure, we should collect the related logs. One simple way is using kubectl logs <Pod<Container--previous cc/
is this related enough to and that you can bundle it in?
The logs from the pods should be retrieved via the api server. This is different from the kubelet logs. I'll upload a PR for this.
Great job It will be very helpful for debugging.
Code change:
"reason":                   "FailedScheduling", }.AsSelector()) expectNoError(err) <ins> // If we failed to find event with a capitalized first letter of reason // try looking for one starting with a small one for backward compatibility. // If we don't do it we end up in #15806. // TODO: remove this block when we don't care about supporting v1.0 too much. if len(schedEvents.Items) == 0 { schedEvents, err = c.Events(ns).List( labels.Everything(), fields.Set{ "involvedObject.kind":      "Pod", "involvedObject.name":      podName, "involvedObject.namespace": ns, "source":                   "scheduler", "reason":                   "failedScheduling", }.AsSelector()) expectNoError(err) } </ins> printed := false printOnce := func(msg string) string {

Related discussion:
text: See Jenkins job kubernetes-upgrade-1.0-1.1-gke-step3-e2e-old's last few runs. The relevant line is . Note that this is running e2e tests off of the branch. It's possible that this is also caused by , but it's not clear to me.
This is also failing on kubernetes-upgrade-1.0-1.1-gke-step5-e2e-old, where we're running tests against a cluster that's been fully upgraded, (master and nodes,) from 1.0 to 1.1.
Status update: this may be caused by , so that issue should be prioritized, but it's not totally clear if that will fix this problem.
said he would take a look and update the issue with any findings. It may be a bit premature to look into it before is resolved, but at least we can try to figure out how to manually repro this now, so that we will know whether fixes this issue.
I'm unable to find logs from failed runs, which makes everything slightly harder. I'll try to reproduce the problem on GCE cluster, but it may not work. FYI: most of was caused by waiting for skydns to come back up (which doesn't happen: ). I see that there's a difference in number of system pods between version 1.1 and 1.0 - there's only 5 of them in 1.1 and 8 of them in 1.0. I'm wondering if this may cause problems in 'old' version of test which we're running there. I'm going to try reproduce it on GCE (as this is the setup I understand better) and if I'll fail I'll try again on GKE.
AFAICT there's a problem with the test, not the upgrade itself. The test from 1.1 branch fails on 1.0 cluster.
It's caused by . Can we please stop renaming things? AFAICT the problem is with test only, everything should be working 'on production'. In v1.0 scheduler Events reasons start with a small letter (e.g. failedScheduling) and v1.0 test is looking for those kind of events to occur. In v1.1 we changed Event reasons to start with a capital letter (e.g.
Code change:
"reason":                   "FailedScheduling", }.AsSelector()) expectNoError(err) <ins> // If we failed to find event with a capitalized first letter of reason // try looking for one starting with a small one for backward compatibility. // If we don't do it we end up in #15806. // TODO: remove this block when we don't care about supporting v1.0 too much. if len(schedEvents.Items) == 0 { schedEvents, err = c.Events(ns).List( labels.Everything(), fields.Set{ "involvedObject.kind":      "Pod", "involvedObject.name":      podName, "involvedObject.namespace": ns, "source":                   "scheduler", "reason":                   "failedScheduling", }.AsSelector()) expectNoError(err) } </ins> printed := false printOnce := func(msg string) string {

Related discussion:
text: FailedScheduling) and modified test accordingly. Effects are obvious. We can: revert patch it to v1.0 merge and patch a test fix which adds handling both versions () I'm for the last option, but whatever we do (except reverting) will break backward compatibility for everyone depending/counting/filtering/whatnot on scheduler Event reasons
thanks for your work on this. From on : Furthermore, in my (rookie) opinion, seems like it should be considered a bug fix rather than an API change. Thus I think makes good sense.
Thanks a lot for debugging this, and I agree we should go with your PR. I talked to Brian and he said we don't consider changes to values of fields in events to be breaking API changes. Unfortunately people do seem to depend on these in various places. One solution is what I proposed in so the compiler could prevent these incompatibilities (at least for components and tests that are compiled together).
+1 to creating a file containing constants for the event reasons that are currently in use.
I'll prepare a cherry pick.
Reopening until cherry pick is merged.
Cherry pick is .
The test mentioned in the first entry in this thread is still failing but not due to the error message related to this issue. Since the cherrypick has been merged, can we close this issue, and followup with additional debugging in ?
Works for me. Thanks to again for your work on this.
I actually still see failures of the same kind in (master 1.1, nodes 1.0) and (master 1.1, nodes 1.1). I assume this is because we haven't cherrypicked test fix into . So this is now a duplicate of .
Code change:
import ( "fmt" "net" <ins> "os" </ins> "strconv" "strings" "testing"

Related discussion:
text: When a --resolv-conf (DNS resolver config) is passed to kubelet on a Windows node, the config content is used as part of sandbox initialization (through getHostDNSConfig()). Now with the recent changes (), it seems now to fail with an error like: E0315 10:22:16. 4764 ] "Error syncing pod, skipping" err="failed to "CreatePodSandbox" for "img-pull-(-b40a-459d-9033-)" with CreatePodSandboxError: "Failed to generate sandbox config for pod "img-pull-(-b40a-459d-9033-)": Unexpected resolver config value: "C:etckubernetescni". Expected "" or "Host"."" pod="img-puller-3842/img-pull-" podUID=-b40a-459d-9033- This is showing on all the runs of GCE testgrid (latest): Reading/using the passed resolv config on Windows Run a Windows pool with DNS resolv config being set as part of kubelet params. No response_ 27 alpha.3 1.27 beta.0 master <detailsGCE </details<details</details<details</details<details</details<details</details
/triage accepted /milestone v1.27 /sig node /sig network
/sig windows /cc
/priority criticial-urgent as this is likely a release blocking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority criticial-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
/priority critical-urgent
Hmm, so you're setting the [1]. This PR introduced the capability to read the DNS config options from the Windows host registries while removing the capability to read from a file, introducing a regression. I've sent a PR addressing this issue: [1]
Is the file you are pointing to a UNIX-style or something else?
Was the file changing the behavior of the node?
Code change:
import ( "fmt" "net" <ins> "os" </ins> "strconv" "strings" "testing"

Related discussion:
text: Yeah, what used on GCE/GKE, seems to be a Linux-like conf, eg: nameserver 10.128.0.1 search c.<project_name.internal google.internal ` We haven't tried to remove from kubelet to see the behavior.
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
I opened up a revert PR in case this PR does not merge by code freeze.
Thanks for the resolution! both 2019 and 2022 grids seems to be back to green now!
Thanks for confirming! I opened to ensure gets updated too