jiebi/CodeConvo huggingface dataset:
Change:
} } <ins> func TestRemoveOutOfDiskCondition(t *testing.T) { now := time.Now() var cases = []struct { desc       string inputNode  *v1.Node expectNode *v1.Node }{ { desc: "should remove stale OutOfDiskCondition from node status", inputNode: &v1.Node{ Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ *makeMemoryPressureCondition(false, now, now), { Type:   v1.NodeOutOfDisk, Status: v1.ConditionFalse, }, *makeDiskPressureCondition(false, now, now), }, }, }, expectNode: &v1.Node{ Status: v1.NodeStatus{ Conditions: []v1.NodeCondition{ *makeMemoryPressureCondition(false, now, now), *makeDiskPressureCondition(false, now, now), }, }, }, }, } for _, tc := range cases { t.Run(tc.desc, func(t *testing.T) { // construct setter setter := RemoveOutOfDiskCondition() // call setter on node if err := setter(tc.inputNode); err != nil { t.Fatalf("unexpected error: %v", err) } // check expected node assert.True(t, apiequality.Semantic.DeepEqual(tc.expectNode, tc.inputNode), "Diff: %s", diff.ObjectDiff(tc.expectNode, tc.inputNode)) }) } } </ins> // Test Helpers: // sortableNodeAddress is a type for sorting []v1.NodeAddress

Discussion:
What happened: removed reporting of the OutOfDisk condition in the kubelet. A 1.12 kubelet upgraded to a 1.13 kubelet leaves the previously reported OutOfDisk condition in place, and it eventually gets switched to Unknown status. What you expected to happen: If this condition is no longer reported, it should be removed by the kubelet. How to reproduce it (as minimally and precisely as possible): a 1.12 kubelet, let it report OutOfDisk condition status. to 1.13 the condition is no longer updated a while, the node controller flips the status to Unknown 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: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /sig node
The fix for this should be picked to 1.13
/assign happened to have a fix handy, if no one is working on it.
after upgrade kubelet should ignore this condition . or change it to 'DiskPressure'
Better not. What if both condition and exist?
should be picked to 1.13 also, I think.
13.2 doesn't have this patch; would it be possible to make it for 1.13.3?
Unfortunately this was not mentioned in the release notes (or I missed it), got hit by this too. 13.2 is affected too, would be good for me to see this getting fixed in 1.13.3
Change:
"least_requested_test.go", "metadata_test.go", "most_requested_test.go", <del> "node_prefer_avoid_pods_test.go", </del> "requested_to_capacity_ratio_test.go", "resource_limits_test.go", "selector_spreading_test.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:
"//staging/src/k8s.io/cri-api/pkg/apis/runtime/v1alpha2:go_default_library", "//third_party/forked/golang/expansion:go_default_library", "//vendor/k8s.io/klog:go_default_library", <ins> "//vendor/k8s.io/utils/net:go_default_library", </ins> ], )

Discussion:
What happened: I tried to create a deployment with duplicate containerPorts with hostIPs of two different address families. Only the first mapping was provided as input into my CNI plugin chain. Also, a log message from kubelet warning about a duplicate containerPort was created. What you expected to happen: Both mappings to be provided as input into my CNI plugins. No log messages should be created. How to reproduce it (as minimally and precisely as possible): Create this deployment: Then grab kubelet logs on the host e.g: Anything else we need to know?: This issue here provides some context as to how I ran into this issue: Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: DigitalOcean, custom setup OS (e.g: ):Kernel (e.g. ):Install tools: None Network plugin and version (if this is a network-related bug): Cilium v1.6.0 and Portmap v0.8.2 Others: N/A I've already identified the problem and will submit a PR which fixes this shortly. /sig network
is this dual-stack only? if so, does the fix for this need to target 1.16?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This applies to dual-stack only yes. I don't know if it should target 1.16, personally I'd like to get this out so I don't have to run a forked version of kubelet.
/assign
I would agree that this should hit v1.16 if possible.
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. ‍
Change:
logPodStates(badPods) return false, nil }) != nil { <del> return errors.New(errorBadPodsStates(badPods, desiredPods, ns, timeout)) </del> <ins> return errors.New(errorBadPodsStates(badPods, desiredPods, ns, "RUNNING and READY", timeout)) </ins> } wg.Wait() if waitForSuccessError != nil {

Discussion:
https://k8s- Failed: BeforeSuite {Kubernetes e2e suite} Previous issues for this test:
Change:
) func TestExtractVmssVMName(t *testing.T) { <del> ss := &scaleSet{} </del> cases := []struct { description        string vmName             string

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 useInstanceMetadata is set to true for vmss nodes, their providerID is wrong. What you expected to happen: Their providerID should be in format azure:///subscriptions/&lt;subscription-id/resourceGroups/&lt;rg-name/providers/Microsoft.Compute/virtualMachineScaleSets/&lt;scaleset-name/virtualMachines/&lt;instance-id 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
adding priority important-soon so that this issue can stay in 1.10. Please update if incorrect. /priority important-soon
Change:
var shPids []int ginkgo.By("checking besteffort container's oom-score-adj") gomega.Eventually(func() error { <del> shPids, err = getPidsForProcess("serve_hostname", "") </del> <ins> shPids, err = getPidsForProcess("agnhost", "") </ins> if err != nil { return fmt.Errorf("failed to get list of serve hostname process pids: %v", err) } if len(shPids) != 1 { <del> return fmt.Errorf("expected only one serve_hostname process; found %d", len(shPids)) </del> <ins> return fmt.Errorf("expected only one agnhost process; found %d", len(shPids)) </ins> } return validateOOMScoreAdjSetting(shPids[0], 1000) }, 2*time.Minute, time.Second*4).Should(gomega.BeNil())

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-node-kubelet-serial Which test(s) are failing: [] Container Manager Misc [Serial] Validate OOM score adjustments [NodeFeature:OOMScoreAdj] once the node is setup pod infra containers oom-score-adj should be -998 and best effort container's should be 1000 Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
/assign
Let's monitor this one and see if worked /reopen /milestone v1.17 /priority critical-urgent
Reopened this issue. <detailsIn response to : Let's monitor this one and see if worked /reopen /milestone v1.17 /priority critical-urgent </details
It seems work well.
These now have 8 successful runs without a single flake. Looks like worked! :smile: 's%20should%20be% cc
thanks /close
Closing this issue. <detailsIn response to : thanks 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:
return err } <del> return wait.Poll(time.Second, b.bindTimeout, func() (bool, error) { </del> <ins> err = wait.Poll(time.Second, b.bindTimeout, func() (bool, error) { </ins> b, err := b.checkBindings(assumedPod, bindings, claimsToProvision) return b, err }) <ins> if err != nil { pvcName := "" if len(claimsToProvision) > 0 { pvcName = claimsToProvision[0].Name } return fmt.Errorf("Failed to bind volumes: provisioning failed for PVC %q: %v", pvcName, err) } return nil </ins> } func getPodName(pod *v1.Pod) string {

Discussion:
What happened: Provisioning of a volume with failed and this event were created on a pod: The event does not say anything useful and only confuses users. What you expected to happen: Either no event (event on PVC about failed provisioning could be enough) or something generic about "waiting for provisioning to finish". How to reproduce it (as minimally and precisely as possible): Tested on AWS. It should be the same with GCE and other block-based in-tree volumes. StorageClass with PVC requesting RWX (so provisioning fails): pod that uses the PVC. Pod events: Anything else we need to know?: I've been able to track down what happens: Scheduler adds to the PVC Provisioner tries to create a volume for the PVC and fails. The annotation is removed in  The scheduler expects that the annotation exists here: I am not sure how to fix it though. Ignoring the error might be the easiest thing to do. Environment: Kubernetes version (use ): today's master /sig storage /sig scheduling /assign
yes, the error message is confusing. "FailedScheduling" event will be emitted if the scheduler failed to schedule the pod. How about wrapping the internal error message in function, e.g. ? Users will know the pod failed because pod volumes not bound successfully. Sometimes, users can't just wait for the scheduler to recover from the error state, manual intervention might be required. The internal reason will be useful. In this scenario, .
's suggestion sounds good to me
Change:
default: jobDuration = duration.HumanDuration(obj.Status.CompletionTime.Sub(obj.Status.StartTime.Time)) } <ins> var status string if hasJobCondition(obj.Status.Conditions, batch.JobComplete) { status = "Complete" } else if hasJobCondition(obj.Status.Conditions, batch.JobFailed) { status = "Failed" } else if obj.ObjectMeta.DeletionTimestamp != nil { status = "Terminating" } else if hasJobCondition(obj.Status.Conditions, batch.JobSuspended) { status = "Suspended" } else if hasJobCondition(obj.Status.Conditions, batch.JobFailureTarget) { status = "FailureTarget" } else { status = "Running" } </ins> <del> row.Cells = append(row.Cells, obj.Name, completions, jobDuration, translateTimestampSince(obj.CreationTimestamp)) </del> <ins> row.Cells = append(row.Cells, obj.Name, status, completions, jobDuration, translateTimestampSince(obj.CreationTimestamp)) </ins> if options.Wide { names, images := layoutContainerCells(obj.Spec.Template.Spec.Containers) row.Cells = append(row.Cells, names, images, metav1.FormatLabelSelector(obj.Spec.Selector))

Discussion:
Suspend is a GA feature and it is big component of Kueue. It would be nice to display if jobs are suspended when doing . A new column that displays if the job is suspended would be helpful. Improve UX around suspend. Its a bit difficult to know why the job has not created pods unless you know about the suspend field.
/sig cli /wg batch /good-first-issue /help-wanted
This request has been marked as suitable for new contributors. 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 cli /wg batch /good-first-issue /help-wanted 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
/cc Just something I noticed as I was testing some job in JobSet. It would be nice to see which jobs are suspended when doing . Hope its not a controversial change.
cc who worked on
Not controversial at all IMO /triage accepted
/assign
Any suggestions on where to place this column? I'm thinking between completions and durations. Or, should this be displayed only when the output is set to wide?
I would put it in the default view as well. Probably before completions
Addressed in the PR:
Change:
factor = 2 ) duration := base <ins> // Responsible for checking limits in resolv.conf // The limits do not have anything to do with individual pods // Since this is called in syncLoop, we don't need to call it anywhere else if kl.dnsConfigurer != nil && kl.dnsConfigurer.ResolverConfig != "" { kl.dnsConfigurer.CheckLimitsForResolvConf() } </ins> for { if err := kl.runtimeState.runtimeErrors(); err != nil { klog.Errorf("skipping pod synchronization - %v", err)

Discussion:
What happened: Ref , we noticed that there are some unnecessary check around limit in kubelet, specifically at: and is moving this check to outside of the pods loop make it better, but we should be looking at whether this check can exist in an even higher layer, as it doesn't make much sense in either or . cc
/sig network
/assign Pending outcome of the discussion here, I would be happy to present a PR
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
poke :-)
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
How about lifting the check to the beginning of Kubelet#syncLoop (outside the for loop) ? All the events emitted by CheckLimitsForResolvConf are at EventTypeWarning level (not error). The CheckLimitsForResolvConf call in HandlePodUpdates would be removed as well.
Change:
kube::log::status "Testing kubectl(${version}:nodes)" <del> kube::test::get_object_assert nodes '{{range.items}}{{.id}}:{{end}}' '127.0.0.1:' </del> <ins> kube::test::get_object_assert nodes "{{range.items}}{{.$id_field}}:{{end}}" '127.0.0.1:' </ins> ########### # Minions #

Discussion:
This works: Are we using /var/run for testing?
Curiously travis shows a similar error message regarding /var/run/kubernetes, but it isn't failing: I suspect the /var/run/kubernetes issue is not what's causing the failure here.
However, I am able to reproduce the failure on my machine. I note that in your case, the fatal error says For me, it says The ip addresses showing through here (which appear to be in the GCE space?) are worrying.
It seems it still failing. I've run it locally and it failed with the following error: The aforementioned line: I think it is expected that there are some pods started by k8s (e.g. elasticsearch). Does it mean the test has a bug?
Strangely the same code () passes tests on travis (https://travis-)
I think you're reading it backwards. The test is expecting no pods to be started, but finding the k8s add-on pods, which is normal if it were running against a normal master. In Travis, it's a synthetic environment with no add-ons. This should be assigned to whoever the checks (on mobile.. I know I merged the PR but don't remember who :)). We need to exclude the add-ons (perhaps by finally getting around to putting them in a separate namespace).
the assertions, so CC'ing for comment.
I looked into this with and it seems that test- may fail locally depending on the kubeconfig. Some commands are using defaults for kubectl and thus sometimes they contact another cluster. I'll send a PR to fix this.
Change:
"type": "string" }, "mountPropagation": { <del> "description": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationHostToContainer is used. This field is alpha in 1.8 and can be reworked or removed in a future release.", </del> <ins> "description": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationHostToContainer is used. This field is beta in 1.10.", </ins> "type": "string" }, "name": {

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: Mount propagation feature was moved to beta in PR However the was not updated to reflect that it is now beta: What you expected to happen: Comment reflects feature is beta. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /assign Environment: Kubernetes version (use ): 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 add a sig label. <detailsA sig label can be by either: 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 . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
I push a PR for it.
Oops, sorry. thanks for the PR.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
Update to make bot happy: PR is approved and ready to merge
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
if port != "443" { t.Fatalf("expected 443 as port, got %q", port) } <ins> } func TestLoopbackHostPortIPv6(t *testing.T) { ipv6, _, err := isIPv6LoopbackSupported() if err != nil { t.Fatalf("fail to enumerate network interface, %s", err) } if !ipv6 { t.Fatalf("no ipv6 loopback interface") } </ins> <del> host, port, err = LoopbackHostPort("[ff06:0:0:0:0:0:0:c3]:443") </del> <ins> host, port, err := LoopbackHostPort("[ff06:0:0:0:0:0:0:c3]:443") </ins> if err != nil { t.Fatalf("unexpected error: %v", err) }

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: LoopbackHostPort code is calling the which depends on the machine on which this test is running. Especially in this particular testase it looks for the ipv6 ip address which does not exist because the machine is not configured for ipv6. Because of the LoopbackHostPort function bahaves based on the interfaces configured, test will fail if machine is not really configured with ipv6. Need to rewrite the testcase to handle such situation. What you expected to happen: Testcase should pass
/sig network
/cc
/triage unresolved I am a bot run by ‍
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. ‍
/remove-triage unresolved
Change:
// If there are still volume directories, do not delete directory volumePaths, err := kl.getPodVolumePathListFromDisk(uid) if err != nil { <del> glog.Errorf("Orphaned pod %q found, but error %v occurred during reading volume dir from disk", uid, err) </del> <ins> orphanVolumeErrors = append(orphanVolumeErrors, fmt.Errorf("Orphaned pod %q found, but error %v occurred during reading volume dir from disk", uid, err)) </ins> continue } if len(volumePaths) > 0 { <del> glog.Errorf("Orphaned pod %q found, but volume paths are still present on disk.", uid) </del> <ins> orphanVolumeErrors = append(orphanVolumeErrors, fmt.Errorf("Orphaned pod %q found, but volume paths are still present on disk.", uid)) </ins> continue } glog.V(3).Infof("Orphaned pod %q found, removing", uid) if err := removeall.RemoveAllOneFilesystem(kl.mounter, kl.getPodDir(uid)); err != nil { glog.Errorf("Failed to remove orphaned pod %q dir; err: %v", uid, err) <del> errlist = append(errlist, err) </del> <ins> orphanRemovalErrors = append(orphanRemovalErrors, err) } } logSpew := func(errs []error) { if len(errs) > 0 { glog.Errorf("%v : There were a total of %v errors similar to this.  Turn up verbosity to see them.", errs[0], len(errs)) for _, err := range errs { glog.V(5).Infof("Orphan pod: %v", err) } </ins> } } <del> return utilerrors.NewAggregate(errlist) </del> <ins> logSpew(orphanVolumeErrors) logSpew(orphanRemovalErrors) return utilerrors.NewAggregate(orphanRemovalErrors) </ins> }

Discussion:
What we see in if any mismatches for volumes are around: The Problem: Obviously this can get pretty large. Since theres not much variability, it seems like rolling up all the orphanXYZ messages would be more useful and readable. Note this runs in the sync loop, so it happens every few (2) seconds for me. Obviously we see this worse on larger nodes (100 * n) / before but , I've only reproduced this on a local cluster for this PR.