jiebi/CodeConvo huggingface dataset:
Change:
- apiGroups: ["extensions", "networking.k8s.io"] resources: ["ingresses/status"] verbs: ["update", "patch"] <del> # GLBC ensures that the `cloud.google.com/backendconfigs` CRD exists in a desired state: # https://github.com/kubernetes/ingress-gce/blob/4918eb2f0f484f09ac9e5a975907a9b16ed2b344/cmd/glbc/main.go#L93 </del> <ins> # GLBC ensures that the `cloud.google.com/backendconfigs` and `networking.gke.io/servicenetworkendpointgroups` CRD exists in a desired state: # https://github.com/kubernetes/ingress-gce/blob/5c3fcb5845e74b92ea8bd52929b15fc5c9fa7970/cmd/glbc/main.go#L108 # https://github.com/kubernetes/ingress-gce/blob/5c3fcb5845e74b92ea8bd52929b15fc5c9fa7970/cmd/glbc/main.go#L133 </ins> # TODO(rramkumar1): https://github.com/kubernetes/ingress-gce/issues/744 - apiGroups: ["apiextensions.k8s.io"] resources: ["customresourcedefinitions"]

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which test(s) are failing: Since when has it been failing: The full testgrid history is red, but it has been failing at least since 5/29 Testgrid link: Reason for failure: Anything else we need to know: Originally these failures were due to an rbac permission issue (see: ), but now that that has been resolved, the tests are still not passing.
/sig network
adding to the milestone for investigation, since ingress was touched this release /milestone v1.19
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
what is the difference between that job and (which seems to be mostly passing)?
/assign
Also assigning since I think he's already looking into this: /assign
Oh nice, prow can actually assign me now
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Sorry for the delay. This has been triaged. The actual issue is that: system:controller:glbc rbac needs patch permissions for "ingresses/status" in I will send a PR for the fix. /remove-triage unresolved
^ PR
looks like that resolved almost all the failures. is still failing
Nice! Looks like this failure is caused by relying on the old static IP behavior. We used to allocate one if the specified one did not exist. I will send a PR to update the test.
can we close this out with ?
Yes, latest run was green:
/reopen Can this be reviewed again please? cc
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
seems to be a RBAC issue?
/cc did ingress-gce just start expecting access to this resource recently? does the RBAC role at need to be updated?
Hi, I've filed to address the issue.
Change:
coreDNSServiceAccount := &v1.ServiceAccount{} if err := kuberuntime.DecodeInto(legacyscheme.Codecs.UniversalDecoder(), []byte(CoreDNSServiceAccount), coreDNSServiceAccount); err != nil { <del> return fmt.Errorf("unable to decode CoreDNS configmap %v", err) </del> <ins> return fmt.Errorf("unable to decode CoreDNS serviceaccount %v", err) </ins> } // Create the ConfigMap for CoreDNS or update it in case it already exists

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: Error message at is "unable to decode CoreDNS configmap %v", err" What you expected to happen: IMHO Error message should be "unable to decode CoreDNS serviceaccount %v", err" in same file and line number as We are decoding serviceaccount for CoreDNS and not configMap. configMap is already done in line 176 in same file. How to reproduce it (as minimally and precisely as possible): Check Anything else we need to know?: I just found it while working on some other PR. I didn't install kubernetes/kubeadm. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS (Xenial Xerus) Kernel (e.g. ): Linux ubuntu 4.10.0-42-generic ~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the and . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area kubeadm
Change:
--logtostderr=true: log to standard error instead of files --match-server-version=false: Require server version to match client version --namespace="": If present, the namespace scope for this CLI request. <del> -s, --server="": The address of the Kubernetes API server </del> <ins> -s, --server="": The address and port of the Kubernetes API server </ins> --stderrthreshold=2: logs at or above this threshold go to stderr --token="": Bearer token for authentication to the API server. --user="": The name of the kubeconfig user to use

Discussion:
If the apiserver only listens on one physical IP, then you'd have to use kubectl --server to specify the host. The help message says specify the IP, connection refused: both IP and Port, then ok: So, is it possbile to default the port to 8080 if no port specified at command line or read it from the config file /etc/kubernetes/apiserver, which is 8080 too. If it's impossible to default the port to 8080, it needs an update of the help message at least, like: or add --port flag.
The options are: the port from the port by trying if none is specified a flag the documentation I think (4) is the way to go (I'm not lazy I swear). (1) requires access to the API server's filesystem which is off-limits. (2) seems like it'll work for some configs and is a default that may change. (3) is more verbose and adds yet another flag. Will send a PR.
Change:
// IsClosed checks if the queue is closed func (f *FIFO) IsClosed() bool { <del> f.closedLock.Lock() defer f.closedLock.Unlock() </del> <ins> f.lock.Lock() defer f.lock.Unlock() </ins> if f.closed { return true }

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: Race conditions found on 2 usages of sync.Cond in client-go/tools/cache.DeltaFIFO and client-go/tools/watch/eventProcessor. I don't know how harmful they are since the buggy interleaving is hard to trigger. They may lead to goroutine leaks to my understanding. They have similar causes and I put them in one issue here for ease of triage. When and are invoked concurrently on an empty queue, the in may miss the signal from . The is guarded by the for-loop below. It appears that should not be called if the FIFO queue is already closed, hence the check at line 475. However, the check above may race with : Specifically, when the queue is empty and not closed, will reach the . Between the check and , another goroutine can call and the broadcast on will be missed. Consequently, may block indefinintely and miss the broadcast on from . Note that holds while and hold . So can interleave with . Here is a stack trace found by our tool while running . The tool is based on the Go race detector. I did some research and found introduced the bug while trying to fix exactly the issue: "stop controller when the stop channel is closed and the queue is empty". The fix doesn't appear to solve the issue completely. One suggested fix: use in and instead of . This would enforce atomicity between the check and in . This is similar to DeltaFIFO. In between and : Another goroutine can call : This would cause the signal on to be missed by the above , leading to the goroutine being blocked unexpectedly. Stack trace from : One suggested fix: use mutex to protect in . What you expected to happen: No race condition. 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: ): MacOS Kernel (e.g. ): Darwin Install tools: Network plugin and version (if this is a network-related bug): Others: This is my first issue filed.

Please let me know if I can provide further information.
/sig api-machinery
For issue 1, in probably the date race is not uncovered due to Run() being long running. If we use f.lock in f.Close() and f.IsClosed(), closedLock is not needed any more. Since f.lock is taken at the beginning of Pop(), we would need lockless version of IsClosed()
Oh..Right. I didn't see this point. Please ignore my suggested fix for issue 1 then.
/cc
Hi, I reproduced the goroutine leak with this test case. The control loop inside may not exit when is called on an empty queue due to the race condition. Also, I submitted a PR trying to fix it. :smile:
Change:
### Hardcoded constants DEFAULT_CNI_VERSION='v0.9.1' DEFAULT_CNI_HASH='b5a59660053a5f1a33b5dd5624d9ed61864482d9dc8e5b79c9b3afc3d6f62c9830e1c30f9ccba6ee76f5fb1ff0504e58984420cc0680b26cb643f1cb07afbd1c' <del> DEFAULT_NPD_VERSION='v0.8.7' DEFAULT_NPD_HASH='853576423077bf72e7bd8e96cd782cf272f7391379f8121650c1448531c0d3a0991dfbd0784a1157423976026806ceb14ca8fb35bac1249127dbf00af45b7eea' </del> <ins> DEFAULT_NPD_VERSION='v0.8.8' DEFAULT_NPD_HASH='ba8315a29368bfc33bdc602eb02d325b0b80e295c8739da35616de5b562c372bd297a2553f3ccd4daaecd67698b659b2c7068a2d2a0b9418ad29233fb75ff3f2' </ins> DEFAULT_CRICTL_VERSION='v1.21.0' DEFAULT_CRICTL_HASH='e4fb9822cb5f71ab8f85021c66170613aae972f4b32030e42868fb36a3bc3ea8642613df8542bf716fad903ed4d7528021ecb28b20c6330448cd2bd2b76bd776' DEFAULT_MOUNTER_TAR_SHA='7956fd42523de6b3107ddc3ce0e75233d2fcb78436ff07a1389b6eaac91fb2b1b72a08f7a219eaf96ba1ca4da8d45271002e0d60e0644e796c665f99bb356516'

Discussion:
/cc Can and npd v0.8.8(with ) fix this problem? /sig node Example: node-problem-  /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
Yes, the and npd v0.8.8(with kubernetes/node-problem-detector) should fix this problem
/triage accepted /assign
There are other files that are needed to be updated, for reference Could you please update.
Change:
<source> type tail format /^time="(?<time>[^)]*)" level=(?<severity>[^ ]*) msg="(?<message>[^"]*)"( err="(?<error>[^"]*)")?( statusCode=($<status_code>d+))?/ <del> time_format %Y-%m-%dT%H:%M:%S.%NZ </del> path /var/log/docker.log pos_file /var/log/es-docker.log.pos tag docker

Discussion:
GCL logging test failed recently, related issue in In the fluentd logs there're a lot of lines like Because apparently this kind of messages in docker logs have different time format Fluentd configuration should be patched to handle this kind of messages. Maybe because of messages like this the logs were not delivered also, maybe fluentd spent too much cpu on docker log to keep up with all log files.
Just for your information, that this might happen with fluentd
cc/
thanks for catching this.
please fill an issue for Docker with the problem
Change:
} // Waits for the pv and pvc to be bound to each other, then checks that the pv's <del> // claimRef matches the pvc. Fails test on errors. </del> <ins> // claimRef matches the pvc. Fails test on errors. Return the pv and pvc to // reflect that these resources have been retrieved again (Get). // Note: the pv and pvc are returned back to the It() caller so that the //   AfterEach func can delete these objects if they are not nil. </ins> func waitAndValidatePVandPVC(c *client.Client, ns string, pv *api.PersistentVolume, pvc *api.PersistentVolumeClaim) (*api.PersistentVolume, *api.PersistentVolumeClaim, error) { var err error

Discussion:
Context: NodeSwap feature gate was recently . Currently, as per , swap is only supported with cgroup v2 - cgroup v1 is no longer supported. For this reason, we decided to fail kubelet if NodeSwap feature gate is enabled and the node runs with cgroup v1. This would help prevent any surprises for the user by failing as soon as possible. This effort is being implemented in this PR: The problem: Currently, swap jobs are running with cgroup v1. Swap tests were in a way that they first check on which environment they're being run (e.g. which cgroup version? is NodeSwap FG enabled? Which swapBehavior is defined? etc) and then expect the right behavior to take place. With v1, the tests expect the containers to be defined without swap access. While the tests pass, they are much less valuable, since all they check is that swap is disabled for v1 workloads. The tests would be much more valuable if they would run with v2, therefore actually ensure that proper swap limitations are configured. In addition, is dependent on these changes, since as of now the jobs immediately fail with this PR since kubelet fails on an environment with cgroup v1 and swap enabled. What needs to change: [x] CRI-O swap related jobs should be defined to run with cgroup v2 (e.g. ) [x] containerd swap related jobs should be defined to run with cgroup v2 (e.g. ). Future work: In the future, we might consider introducing more jobs to check swap. Ideally, both and would be tested, perhaps by periodic jobs.
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
/sig node
/sig testing
/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:
"go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc" "go.opentelemetry.io/otel/trace" "google.golang.org/grpc" <del> "google.golang.org/grpc/codes" </del> "google.golang.org/grpc/credentials/insecure" <del> "google.golang.org/grpc/status" </del> utilfeature "k8s.io/apiserver/pkg/util/feature" tracing "k8s.io/component-base/tracing" "k8s.io/klog/v2"

Discussion:
It "connects" to dockershim There is no Run crictl v1.26.0, without setting up (or using -r) Worked in crictl v1.25.0, that still had CRI v1alpha2 This patch fixed the issue, to make the fallbacks work: <detailsv1.26.0 </details<detailsLima </details<detailsPRETTY_NAME="Ubuntu 22.04.1 LTS" </details<details</details<detailsv1.6.12 </details<details</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
/sig node
I agree that we can check for unavailable connection because it will only be done on kubelet startup.
Change:
} buf := new(bytes.Buffer) err = j.Execute(buf, test.input) <del> if err != nil { </del> <ins> if test.expectError { if test.expectError && err == nil { t.Errorf("in %s, expected execute error", test.name) } continue } else if err != nil { </ins> t.Errorf("in %s, execute error %v", test.name, err) } out := buf.String()

Discussion:
On , will fail to evaluate a filter when the member does not exist: For instance, if I were to execute Where not all in that namespace had the annotation, this would fail with the error message: This is confusing as it leads me to think more than one item was selected, so while it is not technically incorrect the error message is misleading. I would furthermore expect to more gracefully handle this case -- a missing here means that the filter should fail, not error.
What do you mean by ? How is it different from ?
As in, don't add that item to the list of items on which the following access is made. When I do: And there is no annotation on , I just get nothing back -- no error, just nothing. Similarly, i would have expected the filtered expression to give me the for all of the pods that have an annotation with value . That, anyway is what I understand the JSONPath syntax to mean. When you write You are saying:
cc since you authored and I'm not sure how we want to fix this.
Taking a look now
it looks like you need to do this (note that the annotations portion is wrapped by ): I wrote a unit test and it worked as expected. PTAL!
I'm pretty sure that was a typo on my end but let me check -- do you have a reproducer script?
I see an entirely different error today... weird:
Ok so you have 1 object with annotations, and 1 without. Let me look into that case.
Let me add another annotation to
No difference if both have annotations:
Ok, I'll have to test using kubectl
I'm the Origin bundled but I don't think there are any patches on JSONPath there:
I'm able to reproduce in the unit test when 1 object has annotations and the other does not, if allowMissingKeys is true for the jsonpath parser.
I see. Let me know if I can be of more help.
I think I have a fix. PR coming soon.
Possible
Change:
Type:    "DisruptionTarget", Status:  "True", Reason:  "TerminationByKubelet", <del> Message: "The node was low on resource: memory. ", </del> <ins> Message: "The node was low on resource: memory. Threshold quantity: 2Gi, available: 1500Mi. ", </ins> }) }

Discussion:
when the pod is evicted due to low imagefs.available, the prompt is difficult to understand. it showed: But the container was evicted not by exceeding its request of 0 ephemeral-storage, but due to reaching the evictionHard of the node. The correct prompt message points out the reason for the pod eviction. don't print "which exceeds its request of 0.", because the container was evicted not by exceeding its request of 0. % oc label mcp worker custom-kubelet-eviction=small-pods evictionHard by creating a kubeletconfig % oc create -f custom-kubelet- custom-kubelet- several minutes, the mcp worker finish rolling out to the latest mc a pod % oc create -f hello-pod- hello-pod- a large file in container, make imagefs.available < 90Gi (the current available disk size is 111G ) command terminated with exit code 137 the node status the pod status % oc get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-pod-2 0/1 ContainerStatusUnknown 1 7m58s 10.131.0.7 ip-10-0-213- <none<none% oc get pod hello-pod-2 -o yaml No response <details</details<detailsaws </details<details</details<details</details<details</details<details</details
/sig node
/assign
/assign
/triage accepted
Change:
&compbasemetrics.GaugeOpts{ Name:           "apiserver_current_inflight_requests", Help:           "Maximal number of currently used inflight request limit of this apiserver per request kind in last second.", <del> StabilityLevel: compbasemetrics.ALPHA, </del> <ins> StabilityLevel: compbasemetrics.STABLE, </ins> }, []string{"request_kind"}, )

Discussion:
I would like to propose the graduation of the following apiserver metrics from alpha to stable: With the exception of the metric these metrics have been stable for 2 years. The metric has been stable for 12 months.
/sig api-machinery /sig instrumentation
/assign /triage accepted
I'm okay with promoting all of these except I am hesitant about since it is relatively new. Can we omit that one?
I agree with the metric was patched a year ago as part of , so it would be best to wait a bit more until the majority of Kubernetes users catch up to the patched version and start using the new version of the metric in production.
A couple of renaming suggestions, since it is important to get it right before graduation: apiserverresponsesizes =apiserverresponsesizebytes aggregatorunavailableapiservice =aggregatorunavailableapiservices One concern regarding . It was very recently changed but the change was later reverted by In the end, the metric wasn't really changed, but it might raise the concern that some users may still need additional information from this metric so I am on the fence with this one. Side implementation note that we will need to keep in mind if we graduate is that the graduation should only affect the webhook admission metric and not the other, so we will need to pass the stability level to
Thank you and for the feedback. To clarify then, are the decisions to not graduate and final?
I'm actually okay with , the namespace addition was recent but it was a bad idea and was reverted. It has otherwise been in use for quite some time, so I'd be comfortable with promoting it.
I'm willing to make a PR for this one
+1 it wasn't a hard no from my side, just wanted to raise some concerns in case anyone had an objection.
/assign /unassign
Thank you for the feedback, and To summarize, we are in agreement to graduate all but the metric. Please correct me if I'm wrong.
/cc
since all the three metrics that are created with this function are graduating to stable, do you think I should still pass the to the function or should I just set the metrics created by this functions as stable by default? update: Seems like is designed to parse whatever's in front of . So putting a variable there (that is passed to the function) will cause the script to fail. Please correct me if I'm wrong.

update: Even setting the metrics to be stable by default will cause the script to fail and you'll get an error saying for the following line: It appears that the name of the stable metrics should be given to that object as a string and using the output of a function ( in this case) will cause the script to fail.
The PR is ready to be reviewed:
Change:
return strconv.FormatUint(inst.Id, 10), nil } <del> // fqdnSuffix is hacky function to compute the delta between hostame and hostname -f. func fqdnSuffix() (string, error) { fullHostname, err := exec.Command("hostname", "-f").Output() if err != nil { return "", err } hostname, err := exec.Command("hostname").Output() if err != nil { return "", err } return strings.TrimSpace(string(fullHostname)[len(string(hostname)):]), nil } </del> // List is an implementation of Instances.List. func (gce *GCECloud) List(filter string) ([]string, error) { <del> // GCE gives names without their fqdn suffix, so get that here for appending. // This is needed because the kubelet looks for its jobs in /registry/hosts/<fqdn>/pods // We should really just replace this convention, with a negotiated naming protocol for kubelet's // to register with the master. suffix, err := fqdnSuffix() if err != nil { return []string{}, err } if len(suffix) > 0 { suffix = "." + suffix } </del> listCall := gce.service.Instances.List(gce.projectID, gce.zone) if len(filter) > 0 { listCall = listCall.Filter("name eq " + filter)

Discussion:
Actually appending fqdn suffix already causes issue for non-resolvable node names based on today: Today when NodeController "registers" nodes in SyncCloud by getting bare instance names () from GCE, and recreating the fqdn and append it to instance names().