jiebi/CodeConvo huggingface dataset:
Change:
Log_File      /var/log/fluentbit.log Daemon        off Parsers_File  parsers.conf <del> HTTP_Server   off </del> <ins> HTTP_Server   off </ins> HTTP_Listen   0.0.0.0 HTTP_PORT     2020 plugins_file plugins.conf

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: There's a race condition between starting Windows service and when the VMs network is actually available to communicate with the VM's metadata server. If the service starts first and cannot communicate with the metadata server or start talking to the stackdriver logging service it'll crash and not resume because the service is not configured to restart on failure. Typically a is used for a service like this but Windows does not support privileged containers so a standard Windows Service is used. What you expected to happen: If the service fails to start it should be automatically be restarted. How to reproduce it (as minimally and precisely as possible): This is a flaky issue but a way to repro this is to effectively by RDP'ing into the node and running: Anything else we need to know?: Environment: Kubernetes version (use ): v1.16 and onward Cloud provider or hardware configuration: GCE OS (e.g: ): Windows Kernel (e.g. ): Windows (any version) Install tools: cluster/gce/windows/README-GCE-Windows-kube- Network plugin and version (if this is a network-related bug): Others:
/sig windows
/assign jeremyedwards
GitHub didn't allow me to assign the following users: jeremyedwards. 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 jeremyedwards 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:
// These fields are not copied "SessionTicketsDisabled", "SessionTicketKey", <del> "DynamicRecordSizingDisabled", "Renegotiation", </del> // These fields are unexported "serverInitOnce",

Discussion:
When using go 1.7, is failing with the following error:
Emm... I'll need this fix
Wouldn't a full struct copy work if we zero out the fields we don't want retained afterwards? It'll be less fragile as well.
You prefer to re-open my pull request or include that commit in ?
I'm also trouble in the issue when I execute command on release-1.4 branch of Kubernetes. Have someone fixed it? Fails (all fails in ):
, we can not just re-open : in , it did not include & which means build failed in go1.6 if re-open .
BTW, do we still support go1.6 in master? If so, we need upmerge to master.
Is this still a problem? I don't see any test failures on go-1.7.3

Hey Guys, When running command on release-1.4 branch, I got the below errors, my GO version is , how to fix it or something else have I missed?
dup of . fixed by . we can close this. /sig api-machinery
Sure, close it.
Change:
github.com/containerd/containerd/platforms # github.com/containerd/ttrpc v1.0.2 => github.com/containerd/ttrpc v1.0.2 github.com/containerd/ttrpc <del> # github.com/containernetworking/cni v0.8.0 => github.com/containernetworking/cni v0.8.0 </del> <ins> # github.com/containernetworking/cni v0.8.1 => github.com/containernetworking/cni v0.8.1 </ins> ## explicit github.com/containernetworking/cni/libcni github.com/containernetworking/cni/pkg/invoke

Discussion:
is identified with with severity rating as high. This is found using snyk scan while running against k/k master We're not using directly however, it gets tagged for vulnerability scans as we use . The fix is already present in and we can bump the dep. Bump dep to which has the mentioned CVE fix. and check Kubernetes version (use ): n/a Cloud provider or hardware configuration: any OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a /sig architecture /area code-organization for the dependency
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
Change:
o.Prefix = true return o }, <del> expectedOutSubstrings: []string{"[pod/test-sts-0/test-container] test log content for pod test-sts-0n[pod/test-sts-1/test-container] test log content for pod test-sts-1n"}, </del> <ins> expectedOutSubstrings: []string{ "[pod/test-sts-0/test-container] test log content for pod test-sts-0n", "[pod/test-sts-1/test-container] test log content for pod test-sts-1n", }, </ins> }, { name: "pod logs with prefix: init container",

Discussion:
in This flaking test case was newly as part of the above PR Flake was reproducible with stress tool: [root kubernetes]# go version go version go1.22.2 linux/ppc64le [root kubernetes]# stress - ^TestLog /sig testing
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
Looks like in this test case is a concatenation of logs from Pod0 and Pod1, hence it is failing in some cases. I will add a PR to split it.
Change:
expectNoError(err) isReady, err := podRunningReady(p) <del> Expect(isReady).NotTo(BeTrue()) </del> <ins> Expect(isReady).NotTo(BeTrue(), "pod should be not ready") </ins> <del> Expect(getRestartCount(p) == 0).To(BeTrue()) </del> <ins> restartCount := getRestartCount(p) Expect(restartCount == 0).To(BeTrue(), "pod should have a restart count of 0 but got %v", restartCount) </ins> }) })

Discussion:
If the container_probe test runs on a node without the nginx image, it sometimes takes 90s to get the pod in running. Most of this time goes in pulling the image, so I'm assuming it's registry related hiccup. Using might make it more reliable. Example failure: Note the following event in the logs:
a) we should not be pulling from docker in our tests - too hit-or-miss b) we should replace nginx (132 MB) with (4.5 MB) whenever possible. , Prashanth B wrote:
Change:
return nil, err } <del> disks := *vm.StorageProfile.DataDisks </del> <ins> disks := make([]compute.DataDisk, len(*vm.StorageProfile.DataDisks)) copy(disks, *vm.StorageProfile.DataDisks) </ins> bFoundDisk := false for i, disk := range disks { if disk.Lun != nil && (disk.Name != nil && diskName != "" && *disk.Name == diskName) ||

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: In Azure disk attach/detach function, it uses slice() to store the disk list: And after changed, the original would also be changed, so original azure data disk list is corrupted after attach/detach disk example code as below: 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: /sig azure /assign
Change:
"k8s.io/apiserver/pkg/endpoints/request" "k8s.io/apiserver/pkg/features" "k8s.io/apiserver/pkg/registry/rest" <ins> genericfilters "k8s.io/apiserver/pkg/server/filters" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/component-base/tracing" "k8s.io/klog/v2"

Discussion:
Optimize the memory usage of goroutine stack for serving watch requests. According to the of handling a watch request, the stack memory is 0x3768, which is very close to 16 KiB and Golang runtime will double it to 32 KiB once exceeded. In fact, it does exceed if we print the traceback deeper and take the fact that extra stack memory reserved by Golang itself into consideration. A naive optimization is to run as much as preparation handlers in a separate goroutine and then move the actual serving to another goroutine, so the former routine can free the stack memory earlier and make it more memory efficient. Given the extensive use of watch requests, 32 KiB per watch could add up to a very high amount of memory overhead for . A typical watch request commonly lasts for 30s or longer, which means this memory will be active for quite long. I see a great improvement in memory efficiency to do this optimization.
/cc
/sig api-machinery
/cc if you would like to take a look when you have time :) Thank you /triage accepted
Change:
} v, err := conversion.EnforcePtr(listPtr) if err != nil || v.Kind() != reflect.Slice { <del> panic("need ptr to slice") </del> <ins> return fmt.Errorf("need ptr to slice: %v", err) </ins> } if s.pathPrefix != "" {

Discussion:
Remove panic in , please return error instead following .
/sig api-machinery /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 : /sig api-machinery /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
/assign
Please also add some log if returns error
/remove-kind bug /kind cleanup
Change:
return "", err } if !existsLb { <del> return "", fmt.Errorf("Expected to find an IP address for service %s but did not", service.Name) </del> <ins> glog.V(2).Infof("Expected to find an IP address for service %s but did not. Assuming it has been removed", service.Name) return "", nil </ins> } if len(lbStatus.Ingress) < 1 { <del> return "", fmt.Errorf("Expected to find an IP address for service %s but it had no ingresses", service.Name) </del> <ins> glog.V(2).Infof("Expected to find an IP address for service %s but it had no ingresses. Assuming it has been removed", service.Name) return "", nil </ins> } return lbStatus.Ingress[0].IP, nil

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 creating many LoadBalancer services, some services may exceed Azure basic LB's FrontendIPConfiguations quota (default is 10). Public IPs are created for all services, but it is not removed after deleting the kubernetes services. What you expected to happen: Remove the public IP. How to reproduce it (as minimally and precisely as possible): Create more than 10 LoadBalancer services, wait a while for 10 services success, and then remove all services. 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:
/sig azure
/area cloudprovider
Change:
"UsageBytes":      bounded(10*e2evolume.Kb, memoryLimit), "WorkingSetBytes": bounded(10*e2evolume.Kb, memoryLimit), "RSSBytes":        bounded(1*e2evolume.Kb, memoryLimit), <del> "PageFaults":      bounded(0, 1000000), </del> <ins> "PageFaults":      bounded(0, expectedPageFaultsUpperBound), </ins> "MajorPageFaults": bounded(0, expectedMajorPageFaultsUpperBound), }) runtimeContExpectations := sysContExpectations().(*gstruct.FieldsMatcher)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --ci-cos-cgroupv2-containerd-node-e2e <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --<!-- Please see the deflaking doc () for more guidance! --/sig node
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : #### Which jobs are flaking: links to appreciated links to specific failures in spyglass appreciated </details
On cgroupv2, it looks like like the number of for cgroup is sometimes higher than is currently expected in the test. We currently expect this however, in a few runs of the test we've seen We may need to adjust this value similar as was done in for
/cc
yes, good idea. I think we need to adjust the PageFaults test as well. I've opened a PR:
/assign /triage accepted /area test /priority important-soon
Change:
// startupProbe fails, but is disabled m.prober.exec = fakeExecProber{probe.Failure, nil} msg = "Started, probe failure, result success" <del> expectStop(t, w, w.doProbe(), msg) </del> <ins> expectContinue(t, w, w.doProbe(), msg) </ins> expectResult(t, w, results.Success, msg) }

Discussion:
We detected behavior change in v1.21.0 Example: POD has and for some containers Behavior in v1.20.5: starts applied startupProbe success, then start checks for livenessProbe working failed restarted startupProbe applied startupProbe success, then start checks for livenessProbe working Behavior in v1.21.0: starts applied startupProbe success, then start checks for livenessProbe working failed restarted applied, startupProbe skipped not ready yet, killed by liveness check in restart loop So, in v1.21 is applied to "fresh" starts only and not used when container restarted. There is not mentions in changelog that behavior of the is changed. should run on container restarts also. POD with and fail that doesn't apply after container restart Kubernetes version (use ):Cloud provider or hardware configuration: baremetal
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
/assign
Thanks for the quick fix
it was fixed in master (1.22) but not for 1.21, does it need a backport? /reopen
Reopened this issue. <detailsIn response to : it was fixed in master (1.22) but not for 1.21, does it need a backport? /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
/close never mind i just saw the backports.
Closing this issue. <detailsIn response to : /close </details
can you summarize the impacted patch releases (looks like the regression was backported to 1.18-1.20 as well)
These 4 patch releases are impacted, 1.18.18, 1.19.10, 1.20.6, 1.21.0
Change:
ContainersToKill:  map[kubecontainer.ContainerID]containerToKillInfo{}, }, }, <ins> "Verify we do not create a pod sandbox if no ready sandbox for pod with RestartPolicy=OnFailure and all containers succeeded": { mutatePodFn: func(pod *v1.Pod) { pod.Spec.RestartPolicy = v1.RestartPolicyOnFailure }, mutateStatusFn: func(status *kubecontainer.PodStatus) { // no ready sandbox status.SandboxStatuses[0].State = runtimeapi.PodSandboxState_SANDBOX_NOTREADY status.SandboxStatuses[0].Metadata.Attempt = uint32(1) // all containers succeeded for i := range status.ContainerStatuses { status.ContainerStatuses[i].State = kubecontainer.ContainerStateExited status.ContainerStatuses[i].ExitCode = 0 } }, actions: podActions{ SandboxID:         baseStatus.SandboxStatuses[0].Id, Attempt:           uint32(2), CreateSandbox:     false, KillPod:           true, ContainersToStart: []int{}, ContainersToKill:  map[kubecontainer.ContainerID]containerToKillInfo{}, }, }, </ins> "Verify we create a pod sandbox if no ready sandbox for pod with RestartPolicy=Never and no containers have ever been created": { mutatePodFn: func(pod *v1.Pod) { pod.Spec.RestartPolicy = v1.RestartPolicyNever

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: For a Pod with , kubelet would attempt to create a new sandbox for it even after all container succeeded. Logs as below: This issue is similar to which fixed the case of pods whose RestartPolicy are Never. It caused unnecessary CRI and CNI calls, confusing logs and conflicts between the routine that creates the new sandbox and the routine that kills the Pod. It's likely also the root cause of because sometimes the routine that creates the second sandbox and the routine that kills unwanted pod run concurrently, then the netns would be gone when calling CNI. What you expected to happen: kubelet shouldn't create a new sandbox for pod with RestartPolicyOnFailure if all containers succeeded How to reproduce it (as minimally and precisely as possible): Create a pod like this: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 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 node
Created which may fix this.
/assign
Change:
if err != nil { return nil, false, err } <ins> // TODO: expose TTL </ins> creating := false out := e.NewFunc() err = e.Helper.AtomicUpdate(key, out, true, func(existing runtime.Object) (runtime.Object, error) {

Discussion:
The use of AtomicUpdate by genericetcd doesn't handle conflicting writes by rejecting that to a user. It should. Eventually, we may want to hide write conflicts to /pods when status has changed, and to spec when /pods/status changes, but that requires us to have two version counters and that's not worth the effort. Fix incoming.
Also we need a unit/integration test for this.
Change:
if err != nil { return nil, err } <ins> if s.tlsConfig != nil && len(s.tlsConfig.ServerName) > 0 { host = s.tlsConfig.ServerName } </ins> err = conn.VerifyHostname(host) if err != nil { return nil, err

Discussion:
an APIService that routes to an external API server (e.g. service catalog) via a service in namespace a caBundle in the APIService the external API server with a certificate signed for Result: Normal API requests (get/put/post) work as expected Normal watch requests work as expected Upgrade requests (e.g. websocket watch requests) return a 500 error with text like cc
Change:
// // An empty slice *is* equal to a nil slice for our purposes; same for maps. // <del> // Unexported field members are not compared. </del> <ins> // Unexported field members cannot be compared and will cause an imformative panic; you must add an Equality // function for these types. </ins> func (e Equalities) DeepEqual(a1, a2 interface{}) bool { if a1 == nil || a2 == nil { return a1 == a2

Discussion:
This tree has a commit that demonstrates two obviously different objects that should not pass the semantic DeepEqual but do.
What shall we do with this issue for triage? Labels? Priority?
P2 for when he returns , Satnam Singh wrote:
OK I am now sufficiently worried about this. Fixes incoming.
Change:
} } <del> func NewTimeoutError(key, msg string) *StorageError { return &StorageError{ Code:               ErrCodeTimeout, Key:                key, AdditionalErrorMsg: msg, } } </del> func NewInvalidObjError(key, msg string) *StorageError { return &StorageError{ Code:               ErrCodeInvalidObj,

Discussion:
various Oct 30 2023 6pm pst No response Looks like different test are failing with connection timeout errors: One of the tests triggered a core dump: No response /sig
are both suffers from pkg/registry and is from compoent-base, which likely same reason from `
/retitle failing-test: pkg/kubelet/eviction TestManagerWithLocalStorageCapacityIsolationOpen
/sig node
TestManagerWithLocalStorageCapacityIsolationOpen only failed in one of the PRs, so I don't think that specific test is the problem.
ok, rename as see fit. just put owning sigs please for triage.
TestStoreDeleteCollectionWithContextCancellation is the one that seems to be failing across all the failing PRs, so let's start there first. /retitle failing-test: TestStoreDeleteCollectionWithContextCancellation /sig api-machinery
triage link at shows this just starting (happening in CI jobs as well)
image used in the unit test job didn't change around the timeframe this was seen ()
looking for jumps in package unit test runtimes when this failure started happening to see if something is taking longer or stressing the system: ! - cc ! - cc ! - cc Could any of those have introduced changes that could be stressing or exhausting listener connections in unit tests?
the PR in question introduced a poll function around an API call that is unit tested with a fake client i.e. the poll is unit tested, but the fake client has reactors that return error or success right away, so in theory the poll should not be stretched to 1 retries with 1 connection attempts per fake client. while testing locally i did not notice any significant time difference after or the prior i can do some more checks to see what's going on.
merged right at the time the flakes were seen DeleteCollection invokes List, which was modified in that PR to cancel more aggressively cc
I can reproduce about a 10-20% flake rate at HEAD with: failures look like: or while testing that package with , I see ~1300-1500 open connections with this:
Let's revert it then. I looked into it and I don't know from a quick glance why it's failing and I don't have time to debug it now.

I opened
Okay, it looks like we need more debugging to open this PR
one optimization to strip some ~40 fake client connections and 2 seconds from a test:
sounds good, pointed at that commit as well
/triage accepted
Change:
Release: v1.24 Testname: Jobs, apply changes to status Description: Attempt to create a running Job which MUST succeed. <del> Attempt to patch the Job status to include a new start time which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with a new start time which MUST succeed. Attempt to read its status sub-resource which MUST succeed </del> <ins> Attempt to patch the Job status which MUST succeed. An annotation for the job that was patched MUST be found. Attempt to replace the job status with update which MUST succeed. Attempt to read its status sub-resource which MUST succeed </ins> */ framework.ConformanceIt("should apply changes to a job status", func(ctx context.Context) {

Discussion:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig 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
/assign suspecting as cause
Ack, indeed, because this is the suite for alpha features enabled. We have this fix ready for the test itself: /cc
/cc It flakes in
/retitle [Flaking Test] [Conformance] [sig-apps] Job should apply changes to a job status
It used to fail with errors like After it fails with : [FAILED] patched object should have the applied condition with LastTransitionTime time.Date(2024, time.March, 7, 17, 58, 34, 0, time.UTC), got time.Date(2024, time.March, 7, 17, 58, 33, 0, time.Local) instead In [It] at: @ 03/07/24 17:58:34.109 Here I open the follow up fix: PTAL.