jiebi/CodeConvo huggingface dataset:
Change:
eps.Insert(trimmed) } } <del> return eps, nil </del> <ins> // Return immediately when we successfully fetch endpoints if len(eps) > 0 { return eps, nil } // TODO: get rid of this delay #36281 time.Sleep(hitEndpointRetryDelay) </ins> } } <del> return nil, fmt.Errorf("Failed to get endpoints:nTries %dnCommand %vn", minTries, cmd) </del> <ins> return nil, fmt.Errorf("error getting endpoints:nTries %dnCommand %vn", tries, cmd) </ins> } // DialFromNode executes a tcp or udp request based on protocol via kubectl exec

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /priority failing-test /sig network What happened: From https://k8s-, seems to be broken right after they were by Example error message: and Anything else we need to know?: Is it as expected?
Oct 11 16:37:49.106: test session affinity, cost time: 1m31.742990485s This is a mistake. Sorry for my debug lines sneak in. I was just wondering why this test case doesn't run in upstream CI, so I this debug line. Now, I see because this test case only runs in . Oct 11 16:39:42.406: Expect endpoints: map[], got: map[netserver-1:{}] This check failed unexpectedly, let me try to find out why. I am working on it and will let you know soon when I have some updates.
Thanks. These two tests don't run on pull jobs as they are marked as , though https://k8s-, https://k8s- (and other CIs that include ) would have them running.
Do you mean when I raise a PR, these test cases will not be triggered? My question is how can I make sure my follow-up PR can fix this bug? Where can I access the log message when I raise a new PR?
Can I see the updated test results via directly visiting https://k8s-, https://k8s-
Yep, that is the current behavior. A hacky way to make it run on PR --- add a temporary commit to remove the word from test name so some pull jobs ( I think?) will run it. And you could view logs by clicking the button.
Nope, this CI only includes changes that are merged. It is basically a cronjob that runs tests against head.
Change:
], tags = ["automanaged"], deps = [ <ins> "//cmd/kubeadm/app/apis/kubeadm:go_default_library", </ins> "//federation/apis/federation:go_default_library", "//federation/apis/federation/v1beta1:go_default_library", "//federation/client/clientset_generated/federation_clientset:go_default_library",

Discussion:
used to show masters, but as of it no longer does. This is not in accordance with our deprecation policy I believe. cc
That commit/PR is not relevant as there are no supported users/deployment methods that are using label. kubeadm v1.4 or v1.5 was the last. What you're really looking for is who/what removed printing things based on the label...
No blame on you The regression is that we have stopped printing masters in . There may be more to it that a simple revert of , but we should probably start there.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
This has been fixed in recent versions
Change:
volPath := pd.GetPath() if err := os.MkdirAll(volPath, 0750); err != nil { <ins> // TODO: we should really eject the attach/detach out into its own control loop. detachDiskLogError(pd) </ins> return err }

Discussion:
Repro: Create a pod that attempts to mount a GCE PD that is mis-formatted Delete the pod Expected: GCE PD should be detached Observed: GCE PD is not detached.
Chatted with offline and understand the problem with more detail: The basic problem is when filesystem on PD is unformatted, the mount is going to fail. Kubernetes doesn't do cleanup by detaching the PD. Two potential solutions were proposed: 1) use built-in utility: safeformatand_mount in GCE image to format and mount PD to avoid extra step to format the PD disk. 2) Handle mount failure properly. I think we might need handle both anyway. Brendan mentioned that you are looking at a potential new controller for PD, whose responsible is attaching and detaching PD disks. Do you have any latest status on this topic?
No latest status. I haven't done any actual work on it yet. The idea would be to scan the pods assigned to each node, and attaches (or detaches) any PDs that the node needs (or no longer needs). I'm still coming up to speed on a lot of the architectural concepts, so I'd love some guidance.
Now that Tim's volume re-factor has gone in, I'm going to re-visit this issue. Assigning to me.
Change:
require ( github.com/gogo/protobuf v1.3.2 google.golang.org/grpc v1.56.3 <del> k8s.io/apimachinery v0.0.0 </del> ) require ( <del> github.com/go-logr/logr v1.2.4 // indirect </del> github.com/golang/protobuf v1.5.3 // indirect golang.org/x/net v0.17.0 // indirect golang.org/x/sys v0.13.0 // indirect golang.org/x/text v0.13.0 // indirect google.golang.org/genproto/googleapis/rpc v0.0.0-20230525234030-28d5490b6b19 // indirect google.golang.org/protobuf v1.31.0 // indirect <del> k8s.io/klog/v2 v2.100.1 // indirect k8s.io/utils v0.0.0-20230726121419-3b25d923346b // indirect </del> ) <del> replace ( k8s.io/apimachinery => ../apimachinery k8s.io/kms => ../kms ) </del> <ins> replace k8s.io/kms => ../kms </ins>

Discussion:
Drop the and dependencies from to keep the import lighter. /sig auth /triage accepted
/assign Hi, , I created a PR to fix this. I am not sure If I am correct due to the repo seems generated. Would you like to provides some hints for me?
This will likely require a new go module in to move the client-go dep and then mark it as internal, ex: . is the only API machinery dep so we can probably come up with some way to re-implement the wait logic locally? Then we drop these lines so that these imports do not come back again:
Whoa, yeah, I'd take a for loop and a time.Sleep in a test to drop those deps
What is kms using client-go for? Tests only?
These were all needed by the KMS repo back when we had a much more complicated reference implementation which required a key hierarchy. Now they are just used in some tests and mock implementations, so we should be able to simplify things.
I found a place for rate limit. #liggitt
that package just delegates to "", switch that mock provider to use that directly?
Change:
"extender_test.go", "framework_test.go", "main_test.go", <ins> "plugins_test.go", </ins> "predicates_test.go", "preemption_test.go", "priorities_test.go",

Discussion:
What would you like to be : An integration test for NodeResourceLimits plugin. Why is this needed: No end-to-end test coverage current exist for this alpha feature. /sig scheduling /help
/assign /remove-help
Change:
Dump-DebugInfoToConsole Set-PrerequisiteOptions $kube_env = Fetch-KubeEnv <del> Disable-WindowsDefender </del> if (Test-IsTestCluster $kube_env) { Log-Output 'Test cluster detected, installing OpenSSH.'

Discussion:
Two weeks ago we were observing Windows nodes crashing and rebooting during our e2e test runs on GCE (). Analyzing the crash dumps showed a fault in the NTFS driver while the process was running. appears to be part of the Windows Defender anti-malware component. To address the crashes we did two things: 1) disabled Windows Defender on our Windows e2e test nodes (), and 2) included February's Windows updates on our Windows nodes. After these two things the crashes seem to have stopped. Two days ago we re-enabled Windows Defender on our Windows nodes: Unfortunately we started seeing the Windows node crashes again, starting with run 228 on (To determine if a node crash occurred we open the results link for the test run, open the artifacts for each Windows node and look for a file (e.g. )). We analyzed one of these crash dump files and it looked the same as what we saw a couple weeks ago: fault in NTFS while was running. For now we've merged we re-disables Windows Defender on our e2e Windows nodes. Since that PR merged early this morning (starting with run 246) none of our Windows nodes have crashed, strongly implicating Windows Defender as contributing to the crashes. Since the failure is happening in the NTFS driver we'll need help from Microsoft folks to debug it. The memory dump files are publicly available from the test artifacts (runs 228 - 245), and I've copied a WinDbg crash analysis below. Additionally, some Windows version information is available in the serial-1.log file for each Windows node, also copied below. I don't have any great ideas about why the combination of K8s e2e tests and Windows Defender seems to cause the crash; we don't have any other reports of this failure happening in Windows VMs on GCE. Version info: Analysis:
/assign pjh cc is there anyone on your side who can look at this? It's fairly easily reproducible in our e2e test environment. We're working around it for now by disabling Windows Defender; I think we're ok with this for now, but it would be good to find the cause.
/sig windows Not blocking for 1.14.

/cc /cc in case you've seen the same crash
did do some deeper analysis of one of the crash dumps early last week and found this which might be helpful:
cc as well
I fwd'ed the dmp internally
Thanks! also passed this along internally. I'll leave this issue assigned to me while awaiting updates from Microsoft.
The folks at Microsoft root-caused this issue and we've verified a fix for it. The fix will make it into Windows Server 2019 at some point, not sure about the timing for SAC releases.
/assign craiglpeters For tracking.
I believe this issue should be fixed via KB4501371, can you verify once it becomes available?
/assign pjh Yes, I'll verify the fix when that KB is available (end of June).
There's an optional fix out: It will be included in the July cumulative update too
Change:
return "", err } if _, err := os.Stat(filepath.Join(*k8sBinDir, bin)); err != nil { <del> return "", fmt.Errorf("Could not find kube-apiserver under directory %s.", absPath) </del> <ins> return "", fmt.Errorf("Could not find %s under directory %s.", bin, absPath) </ins> } return filepath.Join(absPath, bin), nil }

Discussion:
All the LoadBalancers tests It seems that for a long time IPVS and iptable implementations differ, it may be possible the test do some wrong assumptions? At this point is up to the IPVS maintainers if they want to run those tests or not, is ok if they don't have time to investigate to disable the tests, but we should not have flaky test running or we'll have a lot of noise /sig network /area ipvs /help
/sig network /area ipvs /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig network /area ipvs /help 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:
allErrs = append(allErrs, cErrs.PrefixIndex(i)...) } // Check for colliding ports across all containers. <del> // TODO(thockin): This really is dependent on the network config of the host (IP per pod?) // and the config of the new manifest.  But we have not specced that out yet, so we'll just // make some assumptions for now.  As of now, pods share a network namespace, which means that // every Port.HostPort across the whole pod must be unique. </del> allErrs = append(allErrs, checkHostPortConflicts(containers)...) return allErrs

Discussion:
Pods which use to bind both TCP and UDP sockets to the same port number are rejected with the error: An example pod follows.
Looks like we don't check protocol
The issue was discussed before in , which was closed due to it being low priority.
Hmm, that's 2 pods and the scheduler, this is 2 containers in the same pod and validation at create time. Maybe we should just be more clear about where we stand with hostPort.
Posting here what I posted in the other bug: This can't be worked around when running NFS from a pod. Linux does not allow the NFS port (2049) to be changed, and the Portmap port (111) also cannot be changed. Additionally, you can't separate the UDP from the TCP ports.
Why does NFS need host ports? , Russell Harmon wrote:
Fix is in , Tim Hockin wrote:
Change:
} func getFinishTimeFromContainers(p *v1.Pod) *time.Time { <del> var finishTime *time.Time for _, containerState := range p.Status.ContainerStatuses { if containerState.State.Terminated == nil { return nil </del> <ins> finishTime := latestFinishTime(nil, p.Status.ContainerStatuses, nil) if utilfeature.DefaultFeatureGate.Enabled(features.SidecarContainers) { // We need to check InitContainerStatuses here also, // because with the sidecar (restartable init) containers, // sidecar containers will always finish later than regular containers. names := sets.New[string]() for _, c := range p.Spec.InitContainers { if c.RestartPolicy != nil && *c.RestartPolicy == v1.ContainerRestartPolicyAlways { names.Insert(c.Name) } } finishTime = latestFinishTime(finishTime, p.Status.InitContainerStatuses, func(status v1.ContainerStatus) bool { return names.Has(status.Name) }) } return finishTime } func latestFinishTime(prevFinishTime *time.Time, cs []v1.ContainerStatus, check func(status v1.ContainerStatus) bool) *time.Time { var finishTime = prevFinishTime for _, containerState := range cs { if check != nil && !check(containerState) { continue </ins> } <del> if containerState.State.Terminated.FinishedAt.Time.IsZero() { </del> <ins> if containerState.State.Terminated == nil || containerState.State.Terminated.FinishedAt.Time.IsZero() { </ins> return nil } if finishTime == nil || finishTime.Before(containerState.State.Terminated.FinishedAt.Time) {

Discussion:
Today the function () only account for the regular containers finish time, presumably assuming that init containers have completed before before. However, with the sidecar (restartable init) containers, sidecar containers will always finish later than regular containers. And those needs to be accounted for the calculation. /kind bug The sidecar finish time will be accounted when calculating the job's finish time. Sidecar container with prolonged termination logic on a job will result in incorrect finish time reporting. /sig apps /priority backlog KEP:
/assign
/triage accepted
Change:
maxRetries: maxRetries, } if cl != nil && cl.Core().RESTClient().GetRateLimiter() != nil { <del> metrics.RegisterMetricAndTrackRateLimiterUsage("serviceaccount_controller", cl.Core().RESTClient().GetRateLimiter()) </del> <ins> metrics.RegisterMetricAndTrackRateLimiterUsage("serviceaccount_tokens_controller", cl.Core().RESTClient().GetRateLimiter()) </ins> } e.serviceAccounts = serviceAccounts.Lister()

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: After start kubernetes controller manager, I get the following error: /--------------------- E0726 11:55:39. 1 ] Metric for serviceaccount_controller already registered /--------------------- What you expected to happen: successed to start kube-controller-manager service without error. How to reproduce it (as minimally and precisely as possible): every time. Anything else we need to know?: Environment: Kubernetes version (use ): v1.6.4 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/kind support
fix it, close it.
Change:
0cf8789f-00da-4da0-976a-b6b1dc831159 ``` <del> Add an index.html inside this directory and use `curl` to see this HTML file served up by nginx. </del> <ins> You can also see the mountpoint by inspecting the docker container on that host. </ins> ```sh <ins> $ docker inspect -f "{{.Mounts}}" <container-id> | grep flocker ...{ /flocker/0cf8789f-00da-4da0-976a-b6b1dc831159 /usr/share/nginx/html true} ``` Add an index.html inside this directory and use `curl` to see this HTML file served up by nginx. ```sh $ echo "<h1>Hello, World</h1>" | tee /flocker/0cf8789f-00da-4da0-976a-b6b1dc831159/index.html </ins> $ curl ip ``` <ins> ### More Info Read more about the [Flocker Cluster Architecture](https://docs.clusterhq.com/en/latest/concepts/architecture.html) and learn more about Flocker by visiting the [Flocker Documentation](https://docs.clusterhq.com/). #### Video Demo To see a demo example of using Kubernetes and Flocker, visit [Flocker's blog post on High Availability with Kubernetes and Flocker](https://clusterhq.com/2015/12/22/ha-demo-kubernetes-flocker/) </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/examples/flocker/README.md?pixel)]()

Discussion:
We found that some users coming to the document were getting a little confused. It should include more detail about where to install Flocker services, how to set environment variables, that you can create volumes now with Docker CLI and give more detail in example including how to use it with a spec that includes a replication controller.
Change:
Phase: api.NamespaceActive, }, }, true}, <ins> // Cannot set deletionTimestamp via status update </ins> {api.Namespace{ ObjectMeta: api.ObjectMeta{ Name: "foo"}},

Discussion:
Honestly I'm not sure if this is a bug or a feature, but didn't expect it. Filing this to track.
I think it's a bug. Nothing in the code base depends on it that I can see (edit: namespace deletion does, but only via an in-server call which I'd like to see fixed), and we don't let other delete-related fields mutate during update (deleteGracePeriodSeconds)
Change:
// Checks if a node has sufficient resources, such as cpu, memory, gpu, opaque int resources etc to run a pod. // It returns a list of insufficient resources, if empty, then the node has all the resources requested by the pod. func (f *Fit) Filter(ctx context.Context, cycleState *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status { <del> if !f.enableSidecarContainers && hasRestartableInitContainer(pod) { // Scheduler will calculate resources usage for a Pod containing // restartable init containers that will be equal or more than kubelet will // require to run the Pod. So there will be no overbooking. However, to // avoid the inconsistency in resource calculation between the scheduler // and the older (before v1.28) kubelet, make the Pod unschedulable. return framework.NewStatus(framework.UnschedulableAndUnresolvable, "Pod has a restartable init container and the SidecarContainers feature is disabled") } </del> s, err := getPreFilterState(cycleState) if err != nil { return framework.AsStatus(err)

Discussion:
/kind feature /sig scheduling Filter will return for all nodes when is and is . This can be done is PreFilter. Executing this code in the filter will cause it to be repeated tens of times, with the worst-case scenario being repeated thousands of times. Maybe we should move this to PreFilter like:
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
Sounds reasonable to me :) I think you can go ahead and file a pr for this.
/assign
Sure.
Hi, If you don't mind, I can try to do this.
/assign
Change:
options := api.ListOptions{LabelSelector: selector} rss, err := c.Extensions().ReplicaSets(ns).List(options) Expect(err).NotTo(HaveOccurred()) <del> Expect(rss.Items).Should(HaveLen(0)) </del> <ins> // RSes may be created by overlapping deployments right after this deployment is deleted, ignore them if len(overlapWith) == 0 { Expect(rss.Items).Should(HaveLen(0)) } else { noOverlapRSes := []extensions.ReplicaSet{} for _, rs := range rss.Items { if !strings.HasPrefix(rs.Name, overlapWith) { noOverlapRSes = append(noOverlapRSes, rs) } } Expect(noOverlapRSes).Should(HaveLen(0)) } </ins> framework.Logf("Ensuring deployment %s's Pods were deleted", deploymentName) var pods *api.PodList if err := wait.PollImmediate(time.Second, timeout, func() (bool, error) {

Discussion:
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite} Happened on a presubmit run in .
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment overlapping deployment should not fight with each other {Kubernetes e2e suite}
Looking
Flakes happened when stopping overlapping deployments at clean up step.
You probably need to move the check before the deletionTimestamp check. Just make sure that observedGeneration is updated for the first case.
Because the deployments are overlapping, when deleting one deployment and determining if its RSes are deleted, there might be a race when the other deployment creates an RS
[FLAKE-PING] This flaky-test issue would love to have more attention.