jiebi/CodeConvo huggingface dataset:
Change:
return f.closed } <del> // Pop blocks until an item is added to the queue, and then returns it.  If </del> <ins> // Pop blocks until the queue has some items, and then returns one.  If </ins> // multiple items are ready, they are returned in the order in which they were // added/updated. The item is removed from the queue (and the store) before it // is returned, so if you don't successfully process it, you need to add it back

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 reviewing another PR, I noticed incorrect commentary and code. The primary offense is at , where a comment asserts (incorrectly) that a key can be present in but not and the code removes a key from without ensuring it is absent from . The only saving grace is that this code is actually unreachable (as also noted in the comment). I think it would be better to fix the comment and in this unreachable situation, than to violate an invariant that is critical to other code in this file. also contemplates the possibility that a key can be in and absent from . What you expected to happen: I expected there to be no comments or code that contemplate violations of the invariant at How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): current branch 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:
Sorry, I should have noticed this in my earlier pass over this code.
Agreed. Was discussing this with at
We discussed this one, Mike will send PR, Daniel will review.
Change:
serviceAccountName: csi-hostpathplugin-sa containers: - name: hostpath <del> image: registry.k8s.io/sig-storage/hostpathplugin:v1.7.3 </del> <ins> image: registry.k8s.io/sig-storage/hostpathplugin:v1.9.0 </ins> args: - "--drivername=hostpath.csi.k8s.io" - "--v=5"

Discussion:
For the ReadWriteOncePod feature to graduate to beta, we need to have E2E test coverage for its current alpha behavior. See this section of KEP-2485 for more context on what cases we need to cover for alpha: This is a requirement for beta graduation, see:
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 storage
Change:
cpu: {{hollow_proxy_millicpu}}m memory: {{hollow_proxy_mem_Ki}}Ki - name: hollow-node-problem-detector <del> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.7 </del> <ins> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.8 </ins> env: - name: NODE_NAME valueFrom:

Discussion:
/cc Can and npd v0.8.8(with ) fix this problem? /sig node Example: node-problem-  /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
Yes, the and npd v0.8.8(with kubernetes/node-problem-detector) should fix this problem
/triage accepted /assign
There are other files that are needed to be updated, for reference Could you please update.
Change:
deps = [ "//pkg/api:go_default_library", "//pkg/api/v1:go_default_library", <ins> "//pkg/apis/apps/v1beta1:go_default_library", </ins> "//pkg/apis/extensions:go_default_library", "//pkg/apis/networking:go_default_library", "//vendor/github.com/gogo/protobuf/proto:go_default_library",

Discussion:
Here are the hash label keys of all controllers: Deployment: DaemonSet: (new in 1.7) StatefulSet: (new in 1.7) Had a brief discussion with and about this, it should be consistent. We can use for DaemonSet and StatefulSet, and keep Deployment as-is. Deployment hash label key should be different from other two because Deployment pods hash labels is used by selector (unlike the other two controllers). We probably should have used hash annotations instead of hash labels for DaemonSet and StatefulSet, since we don't use hash labels to select their history or pods. Hash labels are chosen for consistency. This is fine since we don't modify hash label values.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Actually, controller revisions created by statefulset, daemonset has different label: // controller revision created by statefulset label: "" // controller revision created by daemonset label: controller-revision-hash: "" should be consistent?
Change:
testPod.Status.Phase = api.PodFailed fakeWatch.Add(&testPod) <del> select { case <-received: case <-time.After(controllerTimeout): t.Errorf("Expected 1 call but got 0") } </del> <ins> t.Log("Waiting for pod to reach syncHandler") <-received </ins> }

Discussion:
Ran a test executable with more than 20,000 times and no failures. Any hints as to how to get it to show up? I'm running 100 jobs at a time, so my system is stressed already.
I to am unable to reproduce this. I get similar errors if I reduce the timeout at the top of the file. I spent a bit looking at how to rewrite the tests without the timeout, but nothing jumped out at me. Looking at it though, it's really just a 500ms timeout for the test to complete. I'm just going to remove them. Go has a default timeout of 10 minutes. If it's going to pass, it will pass then. If not, Go will give you a nice traceback where it deadlocked.
Change:
deps = [ "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/version:go_default_library", </ins> "//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//staging/src/k8s.io/client-go/rest:go_default_library", ],

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: [] [sig-node] PreStop should call prestop when killing a pod [Conformance] Since when has it been failing: N/A Testgrid link: N/A Reason for failure: When spawning a Pod, it's container might start before all its networking plumbing has been completed. Thus, if the container tests / needs its network connectivity, it mgiht fail. The ` image tries to connect to the Kubernetes API, but if it cannot, the Pod will end up in an Error state. Retrying the Kubernetes API connection will avoid this issue. Anything else we need to know:
/sig node
/remove-sig node /sig testing
Change:
i.interval = slice.get(6) i.transferBits = intOrFail("transfer port", slice.get(7)) i.bandwidthBits = intOrFail("bandwidth port", slice.get(8)) <del> return &i </del> <ins> return &i, nil </ins> } // StrSlice represents a string slice

Discussion:
What happened: The iperf tests were written a while ago but i think havent been updated. They measure bandwidth over multiple pods, but they probably should also have a test which reports individual pod's bandwidth between one pod over a SEP. They should pretty print a table so its easy to see exactly what is going on with the bandwidth They should use iperf3 (need to check that) Maybe we should have permutations for udp and tcp? The current output is something like: What you expected to happen: That running the tests would result in a table such as those that you can get from iperf3, i.e. How to reproduce it: run the e2es on any cluster, Environment: Kubernetes version (use ): master, any version
/sig network
/assign
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I've taken a first pass at this , working on resolving a couple issues then we can circle back to determine how else it could be improved!
Cool c/p the new test output so we can compare when u get a chance
ah yess. much better then what we have now.
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
Change:
// volume types which support fsGroup based ownership(and permissions). // It will have no effect on ephemeral volume types such as: secret, configmaps // and emptydir. <del> // Valid values are "OnRootMismatch" and "Always". If not specified defaults to "Always". </del> <ins> // Valid values are "OnRootMismatch" and "Always". If not specified, "Always" is used. </ins> // +optional FSGroupChangePolicy *PodFSGroupChangePolicy // Sysctls hold a list of namespaced sysctls used for the pod. Pods with unsupported

Discussion:
We need to move this field to beta in 1.20. /sig storage
/triage accepted
According to , is working on a better design on this.
Nope. The current design is the design we are going to use to handle fsgroup. we discussed this at length in sig-storage call.
Is it okay if I make this change?
Change:
// search for attachment by VolumeAttachment.Spec.Source.PersistentVolumeName attachment, err := c.k8s.StorageV1beta1().VolumeAttachments().Get(attachID, meta.GetOptions{}) if err != nil { <del> glog.Error(log("attacher.MountDevice failed while getting volume attachment [id=%v]: %v", attachID, err)) return err </del> <ins> return err // This err already has enough context ("VolumeAttachment xyz not found") </ins> } if attachment == nil { <del> glog.Error(log("unable to find VolumeAttachment [id=%s]", attachID)) return errors.New("no existing VolumeAttachment found") </del> <ins> err = errors.New("no existing VolumeAttachment found") return err </ins> } publishVolumeInfo := attachment.Status.AttachmentMetadata

Discussion:
/kind bug /sig storage What happened: When using a CSI driver that does not support NODESTAGE, I can see orphan json files in that are never cleaned up. What you expected to happen: No orphan file /assign
Change:
// no old objects are left in storage), and then remove the rest of the // versions from this list. // Versions may not be removed from `spec.versions` while they exist in this list. <ins> // +optional </ins> StoredVersions []string `json:"storedVersions" protobuf:"bytes,3,rep,name=storedVersions"` }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, the field on must be explicitly set to their zero-values due to the fact that they are not tagged . Ref: Why is this needed: If using a system that automatically compares the provided configuration to the current, it will produce a diff on the updated status after creation. In addition, making sure to explicitly set to zero-values is not the best user experience. I am happy to provide the fix if this change is approved! /cc /sig api-machinery /area custom-resources
marking them as seems ok, so that client-side validation doesn't complain if they are absent when submitting manifests, but they shouldn't need to be set to omitempty (and at this point, we likely wouldn't change the serialization) Those fields are changed by controllers after creation, so expecting the live API object to exactly match the status is not going to go well anyway.
Good point! I’ll open a fix for this. Yep! The specific system in question ignores fields that are not set at creation time by default when doing comparison, so if status fields are not included then it will not report a diff.
/assign
I opened a fix for this but CC'ed both you and Let me know if any additional effort is required. Thanks!
Change:
func TestGetDevicePrefixRefCount(t *testing.T) { fm := &mount.FakeMounter{ MountPoints: []mount.MountPoint{ <del> {Device: "/dev/disk/by-path/prefix-lun-1", Path: "/mnt/111"}, {Device: "/dev/disk/by-path/prefix-lun-1", Path: "/mnt/222"}, {Device: "/dev/disk/by-path/prefix-lun-0", Path: "/mnt/333"}, {Device: "/dev/disk/by-path/prefix-lun-0", Path: "/mnt/444"}, </del> <ins> {Device: "/dev/sdb", Path: "/127.0.0.1:3260-iqn.2014-12.com.example:test.tgt00-lun-0"}, {Device: "/dev/sdb", Path: "/127.0.0.1:3260-iqn.2014-12.com.example:test.tgt00-lun-1"}, {Device: "/dev/sdb", Path: "/127.0.0.1:3260-iqn.2014-12.com.example:test.tgt00-lun-2"}, {Device: "/dev/sdb", Path: "/127.0.0.1:3260-iqn.2014-12.com.example:test.tgt00-lun-3"}, </ins> }, }

Discussion:
During iscsi volume cleanup, kubelet reads from and retrieves a list of device paths where iscsi volume mounts on. The device path was expected to be in the form of . But currently the device path in is in the form of , thus iscsi panicked . I suspect this panic started to happen after switched to use from . seems to always resolve device path (see output below), and thus the expected iscsi configuration in the device path no longer exists.
Change:
return &ResourceConfig{GroupVersionConfigs: map[schema.GroupVersion]bool{}, ResourceConfigs: map[schema.GroupVersionResource]bool{}} } <ins> // DisableAll disables all group/versions. It does not modify individual resource enablement/disablement. </ins> func (o *ResourceConfig) DisableAll() { for k := range o.GroupVersionConfigs { o.GroupVersionConfigs[k] = false } <del> for k := range o.ResourceConfigs { o.ResourceConfigs[k] = false } </del> } <ins> // EnableAll enables all group/versions. It does not modify individual resource enablement/disablement. </ins> func (o *ResourceConfig) EnableAll() { for k := range o.GroupVersionConfigs { o.GroupVersionConfigs[k] = true } <del> for k := range o.ResourceConfigs { o.ResourceConfigs[k] = true } </del> } // DisableVersions disables the versions entirely.

Discussion:
https://k8s- sample failure: (also affecting other CI jobs) cc /sig gcp
/assign We're interested in disabling the job as blocking entirely. We're of the opinion this shouldn't have bee allowed to block the community in the first place. I swear there's a historical issue around tightening the regex somewhere.
... wrong button sorry about that
possibly caused by erroring on invalid values that were previously silently skipped opened to downgrade that error to a warning for a release
Well, I mentioned the idea of making the job optional in
PR out to drop the runifchanged regex from pull-kubernetes-e2e-gke
Confirmed turns the test green
Can call this closed when merges
/pony hooray
Couldn't find a pony matching that query. <detailsIn response to : /pony hooray 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:
} func (i *internalContainerLifecycleImpl) PreStopContainer(containerID string) error { <del> if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.CPUManager) { </del> <ins> if i.cpuManager != nil { </ins> return i.cpuManager.RemoveContainer(containerID) } return nil } func (i *internalContainerLifecycleImpl) PostStopContainer(containerID string) error { <del> if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.CPUManager) { </del> <ins> if i.cpuManager != nil { </ins> err := i.cpuManager.RemoveContainer(containerID) if err != nil { return err

Discussion:
Recently merged PR () broke clusters brought up with only GA APIs+features. See conformance test at /sig node /priority critical-urgent /kind bug /milestone v1.18 /assign
Change:
"github.com/golang/glog" "github.com/xanzy/go-cloudstack/cloudstack" "k8s.io/api/core/v1" <ins> cloudprovider "k8s.io/cloud-provider" </ins> ) type loadBalancer struct {

Discussion:
/kind bug /sig release Such as:
Cool issue. /assign
I see the code in was pushed by you. I don't understand what Intercept() does. Do you think there is an Infinite recursive call?
Chaos client isn’t used anywhere, and we need to remove it soon.
Ok, I can help remove it.
But there are also one place using it. How to deal with it? Delete it directly? Or something we need to do?
Has never been anything other than experimental and was not used in practice. We can remove it and it’s flag from kubelet as it was experimental. are we deprecating experimental flags for one release or can we just remove?
Change:
&CronJob{}, &CronJobList{}, &api.ListOptions{}, <ins> &api.DeleteOptions{}, </ins> ) scheme.AddKnownTypeWithName(SchemeGroupVersion.WithKind("ScheduledJob"), &CronJob{}) scheme.AddKnownTypeWithName(SchemeGroupVersion.WithKind("ScheduledJobList"), &CronJobList{})

Discussion:
Kubernetes version: HEAD What happened: Using interface to delete Job throws an error . What you expected to happen: Job should be deleted. We've found that issue after dependency update on dashboard: We are using to delete resources. It works fine for all other resources. I've investigated that and it appears to be the core issue. Other groups have registered as a known type. however batch is missing it After adding I was able to successfully delete Job using our code. I can quickly create PR for that. Just need a confirmation that this is indeed a bug. cc
+1 apis/autoscaling is similar
I thought we only needed to register it in the external versions (). I'll double check. cc
Registering api.DeleteOptions in batch looks fine. In the future, I think it's more proper to register DeleteOptions and ListOptions as unversioned, like how we treat .
DeleteOptions and ListOptions are expected to be in their group. They have to be in internal version and external version. Most of this code will be fixed in 1.6 (we'll standardize registering the "common" things). , Chao Xu wrote:
I've created PR to fix this issue. Could anyone check that?
Change:
exit 0 } <del> if (-not (Test-DockerIsInstalled)) { Install-Docker } # For some reason the docker service may not be started automatically on the # first reboot, although it seems to work fine on subsequent reboots. Restart-Service docker Start-Sleep 5 if (-not (Test-DockerIsRunning)) { throw "docker service failed to start or stay running" </del> <ins> $kube_env = Fetch-KubeEnv Set-EnvironmentVars # Install Docker if the select CRI is not containerd and docker is not already # installed. if (${env:CONTAINER_RUNTIME} -ne "containerd") { if (-not (Test-DockerIsInstalled)) { Install-Docker } # For some reason the docker service may not be started automatically on the # first reboot, although it seems to work fine on subsequent reboots. Restart-Service docker Start-Sleep 5 if (-not (Test-DockerIsRunning)) { throw "docker service failed to start or stay running" } </ins> } Set-PrerequisiteOptions <del> $kube_env = Fetch-KubeEnv </del> if (Test-IsTestCluster $kube_env) { Log-Output 'Test cluster detected, installing OpenSSH.'

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 --Docker is always installed on node boot which adds significant start time and adds software that's unnecessary. containerd Windows nodes should not have Docker installed. Start a Kubernetes GCE Windows cluster via kube-up. You can run stuff like on it. 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 windows /triage accepted
Change:
crdClient client.CustomResourceDefinitionsGetter, ) *ConditionController { c := &ConditionController{ <del> crdClient: crdClient, crdLister: crdInformer.Lister(), crdSynced: crdInformer.Informer().HasSynced, queue:     workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "non_structural_schema_condition_controller"), </del> <ins> crdClient:          crdClient, crdLister:          crdInformer.Lister(), crdSynced:          crdInformer.Informer().HasSynced, queue:              workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "non_structural_schema_condition_controller"), lastSeenGeneration: map[string]int64{}, </ins> } crdInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc:    c.addCustomResourceDefinition, UpdateFunc: c.updateCustomResourceDefinition, <del> DeleteFunc: nil, </del> <ins> DeleteFunc: c.deleteCustomResourceDefinition, </ins> }) c.syncFn = c.sync

Discussion:
/sig api-machinery /kind bug /assign sttts because the controller that maintains the condition runs multiple instances in HA apiserver clusters, the controller must not duel in cases where the validation messages change slightly between releases
Change:
"//pkg/apis/componentconfig:go_default_library", "//pkg/kubelet/api:go_default_library", "//pkg/kubelet/api/v1alpha1/runtime:go_default_library", <ins> "//pkg/kubelet/cm:go_default_library", </ins> "//pkg/kubelet/container:go_default_library", "//pkg/kubelet/dockershim/cm:go_default_library", "//pkg/kubelet/dockertools:go_default_library",

Discussion:
Kubernetes version (use ): v1.5.0-alpha.1.2189+-dirty docker: 1.12.3 Environment: fedora24 docker-engine-1.12.3-1.fc24.x86_64 What happened: if docker Cgroup Driver=cgroupfs, and set --cgroup-driver=systemd in kubelet, then enable --experimental-cgroups-per-qos=true; The container cgroup some is not correct. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: 1) docker Cgroup Driver=cgroupfs and --cgroup-driver=cgroupfs in kubelet works well 2) docker Cgroup Driver=systemd and --cgroup-driver=systemd in kubelet works well
help check, thanks.
In Kubernetes 1.6, we can work to detect this case and return an error. IMHO its a configuration error to have docker running with a cgroupfs driver paired with the kubelet running the systemd cgroup driver. /cc
We can also document the compatibility matrix for now.
Change:
podState, ok := cache.podStates[key] if !ok { <del> return nil, fmt.Errorf("pod %v does not exist", key) </del> <ins> return nil, fmt.Errorf("pod %v does not exist in scheduler cache", key) </ins> } return podState.pod, nil

Discussion:
/kind bug There are several error messages in the scheduler cache that are confusing to read, at least one of these surfaced up to end users via Events. I noticed these two in particular but there may be others: Whether or not these should actually be surfacing as events, the messages should be cleaned up.
cc
Seems that these are internal or implement details in scheduler, do our end users can fully understand what the events really mean? I think it is depend on our own implement. idea?
I believe, the problem is with in the message but I am not able to reproduce it, can you please share steps to reproduce this.
No unfortunately, one of our users reported seeing it when there system was in a bad state, not in a reproducible way. The point of the issue is just that the grammar in those messages is bad, which should be fixable even if you can't get them to fire.