jiebi/CodeConvo huggingface dataset:
Change:
} func (n *NodeInfo) Clone() *NodeInfo { <del> pods := append([]*api.Pod(nil), n.pods...) </del> clone := &NodeInfo{ node:                n.node, <del> pods:                pods, </del> requestedResource:   &(*n.requestedResource), nonzeroRequest:      &(*n.nonzeroRequest), allocatableResource: &(*n.allocatableResource),

Discussion:
There are duplicated assignments for , one place is and the other one is . I think we can remove one. The related PR is What do you think about it?
Sure - let's remove the first one.
ok! :)
fixed. I am going to close this issue. Thanks!
Change:
"least_requested.go", "metadata.go", "most_requested.go", <del> "node_prefer_avoid_pods.go", </del> "priorities.go", "reduce.go", "requested_to_capacity_ratio.go",

Discussion:
/sig scheduling /priority important-soon See as an example. Part of This shouldn't need a PostFilter Plugin, it is not worth caching the result of metav1.GetControllerOf. /assign
Change:
return nil } <del> err, patchErr := c.PatchOrReplace(drainer.Client, false) </del> <ins> err, patchErr := c.PatchOrReplaceWithContext(drainer.Ctx, drainer.Client, false) </ins> if err != nil { if patchErr != nil { return fmt.Errorf("cordon error: %s; merge patch error: %s", err.Error(), patchErr.Error())

Discussion:
What would you like to be : For , the method of the object should accept a user supplied context which is then used by the client to update the status of the node before cordon/uncordoning the node. Why is this needed: Currently uses a local copy of the drain/cordon code from the codebase. Instead of maintaining a local copy, we would like to incorporate the functionality using upstream imports from . In the CAPI codebase, we pass a object to all the controller Reconcile routines and sub-routines. We would like to keep this same behavior even when we move to importing the drain code from I noticed that the code at does not use a passed context but instead uses a placeholder context for the patch/update calls. Instead, we can modify the method to accept a custom context passed over from the drain helper.
/sig cli
/triage accepted /priority backlog
Change:
func main() { command := app.NewKubeletCommand() <del> // kubelet uses a config file and does its own special // parsing of flags and that config file. It initializes // logging after it is done with that. Therefore it does // not use cli.Run like other, simpler commands. code := run(command) </del> <ins> code := cli.Run(command) </ins> os.Exit(code) } <del> func run(command *cobra.Command) int { command.SetGlobalNormalizationFunc(cliflag.WordSepNormalizeFunc) return cli.Run(command) } </del>

Discussion:
When running kubelet, if the Run function fails, the returned error has no output, and the cause of the error cannot be located. such as After the error is returned, there is no position output, so the user cannot know the cause of the error. But previous versions had log output Run the Run function, when there is an error exit, print the error log Misconfigured cgroupRoot No response <details</details<details</details<details</details<details</details<details</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
/assign
/sig node
/cc
Change:
return localCache, nil } <del> if ss.Config.VmssVirtualMachinesCacheTTLInSeconds == 0 { ss.Config.VmssVirtualMachinesCacheTTLInSeconds = vmssVirtualMachinesCacheTTLDefaultInSeconds } return azcache.NewTimedcache(time.Duration(ss.Config.VmssVirtualMachinesCacheTTLInSeconds)*time.Second, getter) </del> <ins> return azcache.NewTimedcache(vmssVirtualMachinesCacheTTL, getter) </ins> } func (ss *scaleSet) deleteCacheForNode(nodeName string) error {

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: When a node is deleted and then recreated in short time, the "instance not found" error would be reported from Azure cloud provider and hence the node object is deleted by kube-controller-manager. It is because the deleted VMSS VM would be cached for 15 minutes (this is used to avoid throttling issues when a large number of nodes are deleted): The cache above is too long and should be reduced to a shorter value, e.g. 3 minutes. What you expected to happen: The newly created Node should not be deleted. 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: /kind bug /priority critical-urgent /area provider/azure /sig cloud-provider
is anyone already working on this?
is working on a fix for this. Would you like to have a look?
will do
Thank you for working on this, and /assign
Change:
Expect(err).NotTo(HaveOccurred()) } <del> type eventPatterns struct { reason  string pattern []string } func checkPodEvents(config *localTestConfig, podName string, ep *eventPatterns) { var events *v1.EventList selector := fields.Set{ "involvedObject.kind":      "Pod", "involvedObject.name":      podName, "involvedObject.namespace": config.ns, "reason":                   ep.reason, }.AsSelector().String() options := metav1.ListOptions{FieldSelector: selector} events, err := config.client.CoreV1().Events(config.ns).List(options) Expect(err).NotTo(HaveOccurred()) Expect(len(events.Items)).NotTo(Equal(0)) for _, p := range ep.pattern { Expect(events.Items[0].Message).To(ContainSubstring(p)) } } </del> // The tests below are run against multiple mount point types // Test two pods at the same time, write from pod1, and read from pod2

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!--What happened: Based on discussion , events can be throttled and should not be used to validate failure conditions in e2e tests. We should remove the event checks from subpath and local pv tests and just wait for pod failure. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
could you help look at this for local PV tests?
sure /assign
/area deflake
"Invalid AWS KMS key" also waits for an event

<!-- 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: fsgroup tests are flaking 1-2 times a day: https://k8s- Some test logs: https://k8s- https://k8s-
could you take a look?
I'll look into this.
I found why the tests failed, see my analysis of logs: I created a PR () trying to fix the issue. I am still investigating kubelet and trying to reproduce the issue locally.
/assign
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. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/lifecycle frozen
Change:
# # TODO(#8867) Enable by default. ENABLE_METADATA_CONCEALMENT="${ENABLE_METADATA_CONCEALMENT:-false}" # true, false <ins> METADATA_CONCEALMENT_NO_FIREWALL="${METADATA_CONCEALMENT_NO_FIREWALL:-false}" # true, false </ins> if [[ ${ENABLE_METADATA_CONCEALMENT:-} == "true" ]]; then # Put the necessary label on the node so the daemonset gets scheduled. NODE_LABELS="${NODE_LABELS},beta.kubernetes.io/metadata-proxy-ready=true"

Discussion:
you this variable - PTAL
/sig gcp
Ping? I see that in all failure log messages for . Not sure if thats the cause or just an error message I can ignore?
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. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign since I bumped into this
Change:
''' ret = {'name': name, 'changes': {}, 'result': False, 'comment': ''} <del> iptables_rule = { </del> <ins> iptables_rule_1 = { </ins> 'table': 'nat', 'chain': 'POSTROUTING', 'rule': '-o eth0 -j MASQUERADE ! -d 10.0.0.0/8' } <ins> iptables_rule_2 = { 'table': 'nat', 'chain': 'POSTROUTING', 'rule': '-s %s -j MASQUERADE ! -d %s' % (cidr, cidr) } </ins> def bridge_exists(name): 'Determine if a bridge exists already.'

Discussion:
Spin up a cluster. Create a container on each of two machines. Try to ping each other's IPs. No love. It seems we need an extra iptables rule. For example, for a minion with the 10.244.2.0/24 subnet assigned, we need: iptables -t nat -A POSTROUTING -s 10.244.2.0/24 ! -d 10.244.2.0/24 -j MASQUERADE
Hrm, I can't repro this. I tried: ping 10.244.2.1 from a different kubernetes VM and it worked. (or do you mean from inside a container?)
From within a container to another container
repro'ed it for me, too.
Is this just ping? Or is this any network traffic? , Tim Hockin wrote:
Any traffic - the kernel is not masquerading it because our iptables magic doesn't match packets coming from inside a container on a veth. I saw this while trying to do another round of perf tests.
Change:
# keep request = limit to keep this container in guaranteed class limits: cpu: 10m <del> memory: 20Mi </del> <ins> memory: 50Mi </ins> requests: cpu: 10m <del> memory: 20Mi </del> <ins> # Note that this container shouldn't really need 50Mi of memory. The # limits are set higher than expected pending investigation on #29688. # The extra memory was stolen from the kubedns container to keep the # net memory requested by the pod constant. memory: 50Mi </ins> args: - -cmd=nslookup kubernetes.default.svc.$DNS_DOMAIN 127.0.0.1 >/dev/null - -port=8080

Discussion:
Observed weird memory spikes for both the dns healthz and kube-dns pods in production. Kube-dns didn't oom because there's enough headroom, but healthz did. I can't explain the spikes yet. I tried a bunch of different repros: no , bad nslookup command, sharing the node with cpu hogs etc, but was unable to trigger it. The memory grows, but stays under 10Mi. As a short term mitigation, we stole some ram from kube-dns, because it was always comfortably within limits. Related b/
can be closed -- healthz has been removed
-- close issue?
Change:
// run starts the goroutine to pump from podBackoffQ to activeQ func (p *PriorityQueue) run() { go wait.Until(p.flushBackoffQCompleted, 1.0*time.Second, p.stop) <ins> go wait.Until(p.flushUnschedulableQLeftover, 30*time.Second, p.stop) </ins> } // Add adds a pod to the active queue. It should be called only when a new pod

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The scheduler places unschedulable pods in "unschedulabe" queue and retries them only when certain events happen that could potentially make them schedulable. This logic works well in almost all scenarios, but inevitable race condition in large distributed systems, could potentially cause some events to be seen before pods are to the unschedulable queue. If this happens, pods may be left in the unschedulable queue and not be retried. Such scenarios should be rare and even if they occur, usually there are other events that trigger a retry and cover them. However, if such scenarios happen in smaller and low churn clusters, other events may not be seen for a while and pods may be stuck in the unschedulable queue for a long time. The scheduling queue () has a method that is triggered every second to move backed off pods to the active queue. We should add another go routine that is triggered every 30 seconds and moves pods whose last schedule time is older than 1 minute from "unschedulble" queue to the active queue. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug I don't know if this should be marked as a bug. I don't have any report of such issue. It is more of a precaution to prevent issues. /sig scheduling
I am worried if this will lead to continuous repeated scheduling failures?
What is the problem with repeated scheduling failures? The scheduler had a FIFO until recently. It used to keep retrying unschedulable pods all the time.
can I take this?
Sure, thanks!
GitHub didn't allow me to assign the following users: denkensk. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign 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
It increases the schedule possibility of unschedulble pods and the chances of scheduling failures. Should we also consider latter?
Change:
err = proxier.iptables.RestoreAll(proxier.iptablesData.Bytes(), utiliptables.NoFlushTables, utiliptables.RestoreCounters) if err != nil { klog.Errorf("Failed to execute iptables-restore: %v", err) <ins> metrics.IptablesRestoreFailuresTotal.Inc() </ins> // Revert new local ports. klog.V(2).Infof("Closing local ports after iptables-restore failure") utilproxy.RevertPorts(replacementPortsMap, proxier.portsMap)

Discussion:
What would you like to be : kube-proxy should expose better metrics around tracking success and failures. Administrators should be able to alert on failure counts. Why is this needed: There are several motivating cases: iptables lock contention causes to fail at an increasing rate as services + endpoints grows or are failing to execute Ultimately, there is essentially no feedback from kube-proxy if it fails to program the service network. This makes it annoyingly difficult to debug when things go wrong. As many reasonable hints we can provide should be . /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
is anyone working one this..
what cases do you think are poorly covered? /assign
thanks for triaging this :-) The specific cases are when fails - that function logs an error but doesn't otherwise surface any information. We should have a top-level metric for failing, along with any other lower-level metrics that might make sense for administrators, e.g. fails, fails.
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. ‍
/help-wanted
/assign
Change:
framework.ExpectNoError(err, fmt.Sprintf("Error creating client for cluster %q: %+v", clusterConf.name, err)) return restConfig } <ins> func GetZoneFromClusterName(clusterName string) string { // Ref: https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-util.sh#L55 prefix := "federation-e2e-" + framework.TestContext.Provider + "-" return strings.TrimPrefix(clusterName, prefix) } </ins>

Discussion:
In federation tests, if we observe the build logs. we see cleaning up LoadBalancer from cloud provider seems not working. It has 2 effects: delays the tests by waiting to delete but always returns error. so we waste like 5 minutes. maybe we are leaking the LoadBalancer in the project.
we can see these errors in every build. but just for reference here are some build logs https://k8s-
cc
All the errors in logs are . It doesn't necessarily indicate we are leaking resource, just now we must have clusterID initialized before calling EnsureLoadBalancerDeleted(). Would be better to not call this function directly in e2e test :)
Federation cleanup should use the same implementation as non-federated e2e test:
function looks like only specific to GCE. in future we would run the e2e tests in AWS too. it would be better to use generic functions if any.
using is working for us. here is the test logs https://k8s-
EnsureLoadBalancerResourcesDeleted() actually cleans up nothing, it only lists forwarding rules and probably logging :)
Change:
Logf("Failed to delete static ip %v: %v", name, delErr) } } <del> Failf("Failed to allocated static ip %v: %v", name, err) </del> <ins> Failf("Failed to allocate static ip %v: %v", name, err) </ins> } <ins> ip, err := gceCloud.GetGlobalAddress(name) if err != nil { Failf("Failed to get newly created static ip %v: %v", name, err) } </ins> cont.staticIPName = ip.Name Logf("Reserved static ip %v: %v", cont.staticIPName, ip.Address) return ip.Address

Discussion:
/kind bug What happened: Services of type LoadBalancer (GCE) with IP addresses promoted to static (by user or by orphan) cause the service controller to panic. The constant panicking will cause a reboot loop of the pod. How to reproduce it (as minimally and precisely as possible): a service on GCP it the GCP Console, promote the IP address of the LB to static and set the name to the loadBalancerName which is the same name as the forwarding rule. Environment: Kubernetes version: 1.7.0 AND 1.7.1 Cloud provider or hardware configuration: GCE Symptoms -controller-manager crash loops on the master. Mitigation** Option 1: Build your own version of branch for the master. Only the kube-controller-manager image needs to be updated. Option 2: For all affected services, set the field to the known external IP address. Steps: list of reserved IPs gcloud compute addresses list NAME REGION ADDRESS STATUS us-central1 35.35.35.35 INUSE list of all Services of type LoadBalancer kubectl get svc --all-namespaces | grep "LoadBalancer" default my-service LoadBalancer 10.0.99.201 35.35.35.35 80:/TCP,443:/TCP 58m each service of type LoadBalancer with an IP that's reserved (in the list above), continue to next step. the service's field equal to the known IP. Example_ apiVersion: v1 kind: Service metadata: creationTimestamp: 2017-07-13T00:09:31Z labels: app: echo name: my-service namespace: default resourceVersion: "" selfLink: /api/v1/namespaces/default/services/my-service uid: -675f-11e7-bee2- spec: clusterIP: 10.0.99.201 externalTrafficPolicy: Cluster loadBalancerIP: 35.35.35.35 <------- Field set to below. ports: name: port-1 nodePort: port: 80 protocol: TCP targetPort: 80 name: port-2 nodePort: port: 443 protocol: TCP targetPort: 443 selector: app: echo sessionAffinity: ClientIP type: LoadBalancer status: loadBalancer: ingress: ip: 35.35.35.35
/sig network /assign /area platform/gce
cc
Change:
} assert.Equal(t, expectedWindowsConfig, containerConfig.Windows) } <ins> func TestCalculateCPUMaximum(t *testing.T) { tests := []struct { name     string cpuLimit resource.Quantity cpuCount int64 want     int64 }{ { name:     "max range when same amount", cpuLimit: resource.MustParse("1"), cpuCount: 1, want:     10000, }, { name:     "percentage calculation is working as intended", cpuLimit: resource.MustParse("94"), cpuCount: 96, want:     9791, }, { name:     "half range when half amount", cpuLimit: resource.MustParse("1"), cpuCount: 2, want:     5000, }, { name:     "max range when more requested than available", cpuLimit: resource.MustParse("2"), cpuCount: 1, want:     10000, }, { name:     "min range when less than minimum", cpuLimit: resource.MustParse("1m"), cpuCount: 100, want:     1, }, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { assert.Equal(t, tt.want, calculateCPUMaximum(&tt.cpuLimit, tt.cpuCount)) }) } } </ins>

Discussion:
When submitting a windows pod using resource limits on a node with more than one processor group, the specified count is incorrect due to the usage of which does not take processor groups into account. For example: node with 96 cores cpu limit 94 returns This results in a CPU maximum of since the range is from [1, ]: Our initial goal for this was to limit a process to not use all available CPU and therefore render the node uncontrollable. A CPU maximum of instead of for that specific case. For the calculation, it should use the CPU count for all available processor groups instead of just the current one. Launch a node with a lot of CPUs, for example and schedule the following pod on it: Then SSH into the node and inspect the running container using . The value will be set to . (which just uses ) is able to correctly find out the number of CPUs available to a system. Using for calculation or incorporating that code might solve this issue. <details</details<detailsAzure in-tree </details<details</details<details</details<detailscontainerd://1.6.10 </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 windows
There is already some code which uses GetActiveProcessorCount:
/assign
/triage accepted
Change:
// we confirm unreachability. Logf("Failed to execute %q: %v, stdout: %q, stderr: %q", cmd, err, stdout, stderr) } else { <ins> Logf("maxTries: %d, in try: %d, stdout: %v, stderr: %v", tries, i, stdout, stderr) </ins> var output map[string][]string if err := json.Unmarshal([]byte(stdout), &output); err != nil { Logf("WARNING: Failed to unmarshal curl response. Cmd %v run in %v, output: %s, err: %v",

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.