jiebi/CodeConvo huggingface dataset:
Change:
import ( "fmt" <ins> "strconv" </ins> "strings" "k8s.io/kubernetes/pkg/api" netsets "k8s.io/kubernetes/pkg/util/net/sets" <ins> "github.com/golang/glog" </ins> ) const (

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: AWS m4.2xlarge OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): 4.4.0-36-generic Install tools: kubeadm Others: 1 master and 1 minion What happened: This states that if using kube-proxy will only proxy requests to local endpoints, never forwarding traffic to other nodes and thereby preserving the original source IP address. However when I annotate my NodePort type service with this annotation I see the following error in the logs of kube-proxy of the node where the only pod of the service is running: After this message the service stops working outside of the cluster on the specified NodePort. What you expected to happen: I expected to see that only the with the pod on it serves traffic. How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
Sorry, I have found the issue, I had a setup where the none of the node names were the same as the hostname of the kube-proxy pod and this caused the issue, where none of the Pods running on a hosts were recognised as local pods. I have fixed this issue by manually setting the hostname with in kube-proxy. However I still insist that this error message is misleading and shouldn't be printed in case of NodePort type services, but only for just LoadBalancers.
I met the same problem in the aws cloud providers, by adding - the hostname-override to solve this problem. good
Change:
name = "go_default_test", srcs = [ "attacher_test.go", <ins> "vsphere_volume_block_test.go", </ins> "vsphere_volume_test.go", ], embed = [":go_default_library"],

Discussion:
FEATURE REQUEST: vSphere volume plugin does not support volume device yet. Need to add volumeMode in PV spec as other plugin did. release 1.12
/sig storage
Change:
goldClassName := "gold" now := time.Now() deletionTimestamp := metav1.Time{Time: time.Now().UTC().AddDate(-10, 0, 0)} <ins> snapshotAPIGroup := "snapshot.storage.k8s.io" </ins> testCases := []struct { name               string pvc                *corev1.PersistentVolumeClaim

Discussion:
Currently there's now way for a user to check what they entered in the DataSource field of a PVC create request. In the past, this wasn't as confusing because if one were to submit invalid info (unsupported Kind) the verification checks would fail and the request would be rejected with a helpful message indicating why. As of 1.14 that's no longer the case, a user is able to put anything they wish in these fields and the create is performed and they get a PVC, and there's no way for them to see what is or isn't set. Adding output of DataSource to would be useful, not only for invalid cases where the input might just get eaten, but also for users to have the ability to check for originating sources of their PVCs.
/sig storage
/assign
GitHub didn't allow me to assign the following users: me. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign me 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
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Change:
"//vendor/k8s.io/apiserver/pkg/authentication/serviceaccount:go_default_library", "//vendor/k8s.io/apiserver/pkg/util/logs:go_default_library", "//vendor/k8s.io/client-go/kubernetes:go_default_library", <ins> "//vendor/k8s.io/client-go/plugin/pkg/client/auth:go_default_library", </ins> ], )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: E2E keeps failing with internal Ginkgo failure of "Node 1 disappeared before completing BeforeSuite" on my PR. https://k8s- What you expected to happen: Not that. How to reproduce it (as minimally and precisely as possible): Run /retest on my PR. It's happened 5 times in a row. Anything else we need to know?: I am almost certain my change does not affect that test suite in any way.
cc
Worked on https://k8s- this morning: https://k8s-
Does this repo on an empty changelist?
Looks like it repos on ci: https://k8s-
Talked with gke dev oncall... internal dashboards look fine, doesn't seem like a gke issue.
Most interesting thing on is maybe the prow bump?
I'm seeing this too on my PR
Trying on a clean PR:
Did something bad happen between versions 342 and 346 on 1.11.0-alpha.2? CI fails to start starts: PR:
Maybe this has something to do with
I'm not sure. That was adding permissions back to nodes so they can delete themselves. It had broken downgrades, so it was reverted. It fixed this: https://k8s-
Testing the theory in
looks like no
https://k8s- so absolutely nothing changed on the test-infra side between the last pass at 9:10 and first failure at 9:55 (prow updated before 9a, same kubetest image, test-infra commit) Seems to be failing here : https://k8s- compared to passing run https://k8s- /unassign /assign
The client go auth plugins are by import. kubectl imports the gcp provider explicitly, but the e2e test apparently doesn't. is in the range when the e2e test started failing, and the description of that PR indicates it trimmed lots of dependencies. I'd look at whether the e2e test had only imported that auth plugin indirectly via one of those removed dependencies in that PR. If the e2e test requires that auth plugin, it should import it like kubectl and the kubeapiserver does:
Are you saying the e2e suite imports kubeadm code?

On Fri, May 11, 2018, 19:57 Jordan Liggitt <:
e2e imports kubeadm util: which imports preflight: which imported kubeapiserveroptions prior to : which imported: which imported the apiserver authenticator: which imported the auth plugins:
potential fix in
Thanks Great bug :^)
Change:
runcmd: - systemctl daemon-reload - systemctl enable kube-master-installation.service <ins> - systemctl enable kube-master-internal-route.service </ins> - systemctl enable kube-master-configuration.service - systemctl enable kube-container-runtime-monitor.service - systemctl enable kubelet-monitor.service

Discussion:
If you create a private cluster via kube-up using provider GCE, you won't be able to restart your master nodes. If you restart you master, the nodes won't be able to connect to your master. This is due to this line - It gets executed on master on cluster-up, but it won't be re-executed on master restart. We should fix that, especially if we're to implement /sig scalability /priority important-soon
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 /good-first-issue I'll ask whether someone in SIG Scalability public meeting would like to take on this one
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 : /remove-lifecycle stale /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
Hello, Can I start work on this one as my first issue? :)
I don't see anyone else claiming it, so your contributions are welcome :)
let me know if you need any explanations here
Thank you :) I've made some changes and assign you can you tell me is this will be good approach?
Thanks, I replied in the PR
Change:
}, } <del> kl.podManager.SetPods(pods) // Sync to create pod directories. kl.HandlePodSyncs(pods) for i := range pods { if !dirExists(kl.getPodDir(pods[i].UID)) { t.Errorf("expected directory to exist for pod %d", i) } } </del> <ins> syncAndVerifyPodDir(t, testKubelet, pods, pods, true) </ins> // Pod 1 failed, and pod 2 succeeded. None of the pod directories should be // deleted. kl.statusManager.SetPodStatus(pods[1], api.PodStatus{Phase: api.PodFailed}) kl.statusManager.SetPodStatus(pods[2], api.PodStatus{Phase: api.PodSucceeded}) <del> kl.HandlePodCleanups() for i := range pods { if !dirExists(kl.getPodDir(pods[i].UID)) { t.Errorf("expected directory to exist for pod %d", i) } </del> <ins> syncAndVerifyPodDir(t, testKubelet, pods, pods, true) } func TestDoesNotDeletePodDirsIfContainerIsRunning(t *testing.T) { testKubelet := newTestKubelet(t) testKubelet.fakeCadvisor.On("MachineInfo").Return(&cadvisorApi.MachineInfo{}, nil) testKubelet.fakeCadvisor.On("DockerImagesFsInfo").Return(cadvisorApiv2.FsInfo{}, nil) testKubelet.fakeCadvisor.On("RootFsInfo").Return(cadvisorApiv2.FsInfo{}, nil) runningPod := &kubecontainer.Pod{ ID:        "12345678", Name:      "pod1", Namespace: "ns", </ins> } <ins> apiPod := &api.Pod{ ObjectMeta: api.ObjectMeta{ UID:       runningPod.ID, Name:      runningPod.Name, Namespace: runningPod.Namespace, }, } // Sync once to create pod directory; confirm that the pod directory has // already been created. pods := []*api.Pod{apiPod} syncAndVerifyPodDir(t, testKubelet, pods, []*api.Pod{apiPod}, true) // Pretend the pod is deleted from apiserver, but is still active on the node. // The pod directory should not be removed. pods = []*api.Pod{} testKubelet.fakeRuntime.PodList = []*kubecontainer.Pod{runningPod} syncAndVerifyPodDir(t, testKubelet, pods, []*api.Pod{apiPod}, true) // The pod is deleted and also not active on the node. The pod directory // should be removed. pods = []*api.Pod{} testKubelet.fakeRuntime.PodList = []*kubecontainer.Pod{} syncAndVerifyPodDir(t, testKubelet, pods, []*api.Pod{apiPod}, false) </ins> }

Discussion:
Often observed in logs: However: Which probably means we'd be ok unmounting it: This probably also means we don't delete orphaned mirror pods, which is the next step in SyncPods ().
Change:
// All nonsense below is temporary until we have go versions of these things. func runBash(stepName, bashFragment string) bool { <del> log.Printf("Running: %v", stepName) </del> cmd := exec.Command("bash", "-s") cmd.Stdin = strings.NewReader(bashWrap(bashFragment)) <ins> return finishRunning(stepName, cmd) } func run(stepName, cmdPath string) bool { return finishRunning(stepName, exec.Command(filepath.Join(*root, cmdPath))) } func finishRunning(stepName string, cmd *exec.Cmd) bool { log.Printf("Running: %v", stepName) </ins> stdout, stderr := bytes.NewBuffer(nil), bytes.NewBuffer(nil) if *verbose { cmd.Stdout = os.Stdout

Discussion:
building release, hopefully it's just binary missing; but i expect e2e-test to build binary automatically.
Steps to reproduce? /cc
Just run hack/e2e-, will fail. The _output/go/bin directory only has integration binary. (tried run first, still fails).
Did you try hack/build- first? e2e is in the default target list:
It's also in the client target list in the new build infrastructure:
Ah, I think that will do the trick. I didn't run hack/build-, as I saw e2e- output something like this (A little misleading if it won't build the binary). Re-running test now, will close the issue if it works. But it would be great if the binary will be built automatically.
I agree it should be built automatically. Otherwise, we'd at least have to update our e2e documentation.
Ah, yeah, I ran into this too and haven't fixed it yet. I this cmd/e2e to the build system, where does it end up? Apparently not in _output...
Change:
"fmt" "time" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> utilerrors "k8s.io/apimachinery/pkg/util/errors" utilvalidation "k8s.io/apimachinery/pkg/util/validation" utilfeature "k8s.io/apiserver/pkg/util/feature"

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 --See for more context. What happened: When you set and , you'd expect container cfs quota period to be . However, unless you also set in the feature flags, the quota value will be silently ignored. What you expected to happen: At least a warning be logged if the feature is not enabled but is set. 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 node /assign karan
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig node 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:
apps "k8s.io/api/apps/v1beta1" "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/client-go/tools/record" </ins> "k8s.io/kubernetes/pkg/controller/history" )

Discussion:
An issue to make bot happy for When StatefulSet finds any of its pods in phase Failed it will delete it and create it again. While doing so it will emit delete+create event which is really confusing for the user as he has no idea what's happening. /sig apps
Change:
return nil } <del> var volumeLabels map[string]string if volume.Spec.AWSElasticBlockStore != nil { labels, err := l.findAWSEBSLabels(volume) if err != nil { return admission.NewForbidden(a, fmt.Errorf("error querying AWS EBS volume %s: %v", volume.Spec.AWSElasticBlockStore.VolumeID, err)) } volumeLabels = labels } if volume.Spec.GCEPersistentDisk != nil { labels, err := l.findGCEPDLabels(volume) if err != nil { return admission.NewForbidden(a, fmt.Errorf("error querying GCE PD volume %s: %v", volume.Spec.GCEPersistentDisk.PDName, err)) } volumeLabels = labels } if volume.Spec.AzureDisk != nil { labels, err := l.findAzureDiskLabels(volume) if err != nil { return admission.NewForbidden(a, fmt.Errorf("error querying AzureDisk volume %s: %v", volume.Spec.AzureDisk.DiskName, err)) } volumeLabels = labels } if volume.Spec.Cinder != nil { labels, err := l.findCinderDiskLabels(volume) if err != nil { return admission.NewForbidden(a, fmt.Errorf("error querying Cinder volume %s: %v", volume.Spec.Cinder.VolumeID, err)) } volumeLabels = labels } if volume.Spec.VsphereVolume != nil { labels, err := l.findVsphereVolumeLabels(volume) if err != nil { return admission.NewForbidden(a, fmt.Errorf("error querying vSphere Volume %s: %v", volume.Spec.VsphereVolume.VolumePath, err)) } volumeLabels = labels </del> <ins> volumeLabels, err := l.findVolumeLabels(volume) if err != nil { return admission.NewForbidden(a, err) </ins> } requirements := make([]api.NodeSelectorRequirement, 0) if len(volumeLabels) != 0 { if volume.Labels == nil {

Discussion:
API server latency for PV creation depends on underlying cloud API latency. We have admission plugin that examines incoming PV and adds topology labels and node selector: When the cluster (and cloud) are under pressure, e.g. lot of PVCs are created and dynamically provisioned at one time and attached to nodes, API server latency increases. We've seen cases when we ran out of cloud API request quota and the admission plugin needed to sleep for couple of seconds (on AWS). There should be an easy fix: check, if the created PV already has all necessary labels and topology information and ask the cloud for them only when they're missing. Dynamically provisioned volumes already have these labels. The admission plugin will then ask the cloud only for manually provisioned PVs, which we believe is just a fraction of all PVs in the cluster. There is one glitch: previously, when user created a PV with wrong topology labels, the admission plugin corrected them. With the fix suggested above, this PV won't be corrected. /sig storage cc
Implementation of the above:
Change:
// restart may think these old pods are consuming CPU and we // will get an OutOfCpu error. ginkgo.By("verifying restartNever pods succeed and restartAlways pods stay running") <del> postRestartRunningPods := waitForPods(f, numAllPods, startTimeout) </del> <ins> postRestartRunningPods := waitForPods(f, numAllPods, recoverTimeout) </ins> if len(postRestartRunningPods) < numAllPods { framework.Failf("less pods are running after node restart, got %d but expected %d", len(postRestartRunningPods), numAllPods) }

Discussion:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that fixed it.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze
Change:
for i := range replicas { // delete and recreate failed pods if isFailed(replicas[i]) { <del> glog.V(4).Infof("StatefulSet %s/%s is recreating failed Pod %s", </del> <ins> ssc.recorder.Eventf(set, v1.EventTypeWarning, "RecreatingFailedPod", "StatefulSet %s/%s is recreating failed Pod %s", </ins> set.Namespace, set.Name, replicas[i].Name)

Discussion:
An issue to make bot happy for When StatefulSet finds any of its pods in phase Failed it will delete it and create it again. While doing so it will emit delete+create event which is really confusing for the user as he has no idea what's happening. /sig apps
Change:
mountHeader: mountSecretNames, tokenHeader: tokenSecretNames, } <del> for header, names := range types { </del> <ins> for _, header := range sets.StringKeySet(types).List() { names := types[header] </ins> if len(names) == 0 { w.Write(LEVEL_0, "%st<none>n", header) } else {

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?: /kind bug What happened: unit test fail randomly. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I am working on it.
/sig cli
/kind bug
Thanks for opening the issue. I'm experiencing this too.
Change:
func (ep *endpointsInfo) Cleanup() { Log(ep, "Endpoint Cleanup", 3) <del> if ep.refCount != nil { </del> <ins> if !ep.GetIsLocal() && ep.refCount != nil { </ins> *ep.refCount-- // Remove the remote hns endpoint, if no service is referring it

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 --kube-proxy panics when a LoadBalancer service is created after a deployment it is associated with is created and the pods are fully running. kube-proxy does not panic. 1) Create 2 Windows nodes 2) Create a deployment, ensuring that the pods are scheduled on different nodes: 3) Wait for the pods to go into the state. kube-proxy will not crash if the pods are not fully deployed 4) Create a LoadBalancer service for the deployment 5) At this point kube-proxy should have crashed. If not, delete and recreate the LoadBalancer, this should trigger the panic. The kube-proxy exe was run as: Stdout/err shows: Full kube-proxy logs: Kubernetes version (use ): 1.20 Cloud provider or hardware configuration: AWS OS (e.g: ): Windows server 2019 Kernel (e.g. ): 10.0..1817 Install tools: OpenShift 4.7.3 Network plugin and version (if this is a network-related bug): Hybrid OVN Others:
/sig windows
are you aware of anything happening here?
I am taking a look at this.
/triage accepted