jiebi/CodeConvo huggingface dataset:
Change:
hostSystemType             = "HostSystem" ) <del> var ( nameToNodeInfo        = make(map[string]*NodeInfo) vcToZoneDatastoresMap = make(map[string](map[string][]string)) ) </del> <ins> // NewNodeMapper returns a new NodeMapper func NewNodeMapper() *NodeMapper { return &NodeMapper{ nodeInfoRWLock:        &sync.RWMutex{}, nameToNodeInfo:        make(map[string]*NodeInfo), vcToZoneDatastoresMap: make(map[string](map[string][]string)), } } </ins> // GenerateNodeMap populates node name to node info map func (nm *NodeMapper) GenerateNodeMap(vSphereInstances map[string]*VSphere, nodeList v1.NodeList) error {

Discussion:
Command run: vSphere intree volume test suite occasionally failed with the following error: The test suite should always pass. We may have a chance to hit this by running ` No response binary version: 1.27.4 </details<detailsvsphere </details<details</details<details</details<details</details<details</details
/assign
/sig testing storage ?
/triage accepted
Change:
# Increase the allowed number of open file descriptors ulimit -n 65536 <ins> mount-master-pd </ins> tar xzf kubernetes-server-linux-amd64.tar.gz kubernetes/server/bin/kube-scheduler --master=127.0.0.1:8080 $(cat scheduler_flags) &> /var/log/kube-scheduler.log &

Discussion:
While running kubemark tests we are facing "no space left on device" problems, because master-disk is not mounted in kubemark.
I'm reopening it for now, since it seems that we are still facing "no space left on device" issues in kubemark scale.
Seems to be fixed by
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" clientset "k8s.io/client-go/kubernetes"

Discussion:
From After , Multi-AZ Clusters tests in 1.19 and 1.20 started timing out as createBalancedPodForNodes is extremely inefficient in scale: for each node (out of 5k), it lists all pods in a cluster serially (each list takes ~5s), which translates to ~7 hours. Optimizing this function by listing pods once and then in memory by Spec.NodeName /kind bug /priority critical-urgent /sig scheduling
/triage accepted
/assign
/reopen Looks that ComputeCPUMemFraction took only 12 minutes, but it stuck later, on It is scheduling one pod per each node: Which is waiting 5s to be ready: 5k nodes * 5s = ~7h
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
/assign Can you do the pod creations in parallel?
Yes, good idea. I'll update to do that
Change:
Minify       bool RawByteData  bool <ins> Context      string </ins> OutputFormat string genericclioptions.IOStreams

Discussion:
/kind bug What happened: Current context was set to cluster1. Ran and got back information about cluster1 instead. What you expected to happen: I expected the output to be the cluster2 information How to reproduce it (as minimally and precisely as possible): Have two contexts in your kube config, A and B Run to set A as current context Run Anything else we need to know?: I'd like to help contribute, so if this is an easy fix, someone point me in the right direction and I'll try to get it done. Environment: Kubernetes version (use ): 1.10.2 OS (e.g. from /etc/os-release): MacOS 10.11.6 Install tools: kubectl was installed via brew
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
/assign Filed
Change:
PVCs:          []*v1.PersistentVolumeClaim{pvc}, SeLinuxLabel:  e2epv.SELinuxLabel, NodeSelection: node, <ins> PVCsReadOnly:  readOnly, </ins> } pod, err := e2epod.CreateSecPodWithNodeSelection(cs, &podConfig, framework.PodStartTimeout) defer func() {

Discussion:
What happened: Running two pods that use the same iSCSI volume, one of them fails with: What you expected to happen: Both pods should be running Anything else we need to know?: It's caused by iscsi volume plugin persiting iSCSI settings into the mount directory itself (e.g. ): volume plugin creates the global mount directory. volume plugin creates there. volume plugin mounts the volume there. This shadows the file, but it's fine, as long as no other pod uses the same volume on the same node. creates a second pod that uses the volume. volume plugin tries to create in the global volume directory. Since the volume is mounted, it will either writes the file to the volume (!) or fails, if the volume is read-only.
/sig storage /assign /priority impotant-soon
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /assign /priority impotant-soon 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
/priority important-soon
Our e2e did not catch this, because they always create only one pod when testing read-only volumes.
Change:
package flock <del> import ( "os" "sync" "golang.org/x/sys/unix" ) var ( // lock guards lockfile. Assignment is not atomic. lock sync.Mutex // os.File has a runtime.Finalizer so the fd will be closed if the struct // is garbage collected. Let's hold onto a reference so that doesn't happen. lockfile *os.File ) </del> <ins> import "syscall" </ins> // Acquire acquires a lock on a file for the duration of the process. This method // is reentrant. func Acquire(path string) error { <del> lock.Lock() defer lock.Unlock() var err error if lockfile, err = os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600); err != nil { return err } defer lockfile.Close() opts := unix.Flock_t{Type: unix.F_WRLCK} if err := unix.FcntlFlock(lockfile.Fd(), unix.F_SETLKW, &opts); err != nil { </del> <ins> fd, err := syscall.Open(path, syscall.O_CREAT|syscall.O_RDWR, 0600) if err != nil { </ins> return err } <del> return nil </del> <ins> // We don't need to close the fd since we should hold // it until the process exits. return syscall.Flock(fd, syscall.LOCK_EX) </ins> }

Discussion:
BUG REPORT: Kubernetes version latest master: Environment: Ubuntu 16.04 LTS, Linux 4.2.0-42-generic: What happened: The doesn't provide mutual exclusion. Two processes can both grab the same flock at the same time. What you expected to happen: Only one process should be able to grab the flock. How to reproduce it (as minimally and precisely as possible): Anything else we need to know: Although the flock doesn't work, the does work. Since we usually specify together with , so the 1st process will exit anyway. However we still need to fix the flock..
cc
Sent a PR to fix this ()
Change:
) // NewProxyServer returns a new ProxyServer. <del> func NewProxyServer(config *proxyconfigapi.KubeProxyConfiguration, cleanupAndExit bool, cleanupIPVS bool, scheme *runtime.Scheme, master string) (*ProxyServer, error) { </del> <ins> func NewProxyServer(o *Options) (*ProxyServer, error) { return newProxyServer(o.config, o.CleanupAndExit, o.CleanupIPVS, o.scheme, o.master) } func newProxyServer( config *proxyconfigapi.KubeProxyConfiguration, cleanupAndExit bool, cleanupIPVS bool, scheme *runtime.Scheme, master string) (*ProxyServer, error) { </ins> if config == nil { return nil, errors.New("config is required") }

Discussion:
https://k8s- https://k8s- cc: /kind bug /priority failing-test
This is at least twice in a week we've had cross break due to a public method signature change not being brought to all platforms () We should do:
I'm lost - the PR in question adds an argument and fixes the call-site - what is broken?
Ahh, I see.
How did that PR get through, if it is so obviously broken on Cross?
Cross build doesn't run 100% of the time as a pre-submit (because it takes so long), and it can't block. It's something sig-testing is tracking, but there isn't a quick fix yet.
Looks like was skipped for that PR: "pull-kubernetes-cross Skipped" not sure why yet.
Cross runs when a file matching: changes, (which needs to be fixed, opening a test-infra issue to expand the regex), but also some files could have build tags without the file name matching () Additionally cross is not blocking (), the underlying bug should be fixed now though so once we get the fix in to k/k we can make it blocking when it does run.
I find has already sent a PR. Thanks!
Change:
}() } <ins> // skipPodSchedule returns true if we could skip scheduling the pod for specified cases. func (sched *Scheduler) skipPodSchedule(pod *v1.Pod) bool { // Case 1: pod is being deleted. if pod.DeletionTimestamp != nil { sched.Recorder.Eventf(pod, nil, v1.EventTypeWarning, "FailedScheduling", "Scheduling", "skip schedule deleting pod: %v/%v", pod.Namespace, pod.Name) klog.V(3).Infof("Skip schedule deleting pod: %v/%v", pod.Namespace, pod.Name) return true } // Case 2: pod has been assumed and pod updates could be skipped. // An assumed pod can be added again to the scheduling queue if it got an update event // during its previous scheduling cycle but before getting assumed. if sched.skipPodUpdate(pod) { return true } return false } </ins> type podConditionUpdaterImpl struct { Client clientset.Interface }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Similar problem as , howerver in our case, pod's annotation was updated at scheduling cycle, so it had not been assumed when its annotation was updated. We also need to deal with this case. Detailed steps: a pod . tried to schedule the pod. Then it was prediated by a filter plugin that we write. This plugin modified the pod's annotation to record something. Because pod's annotation changed, scheduuler received a pod update event, and put the pod to the schedule queue again. scheduled the pod successfully for this schedule cycle. tried to schedule the updated pod again(it was put to the schedule queue at step 2). If the pod was scheduled sucessfully, we would see the error log() in scheduler. If scheduler failed to schedue the pod, scheduler would send a failed scheduler event to pod. They are both confusing because the pod had already been successfully. ! Why is this needed: It will be better to handle pod annotation updates during scheduling more gracefully. /kind cleanup /sig scheduling /assign
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --1. Created a pod . Scheduler tried to schedule the pod. Then it was prediated by a filter plugin that we write. This plugin modified the pod's annotation to record something. Because pod's annotation changed, scheduuler received a pod update event, and put the pod to the schedule queue again. Scheduler scheduled the pod successfully for this schedule cycle. Scheduler tried to schedule the updated pod again(it was put to the schedule queue at step 2). If the pod was scheduled sucessfully, we would see the error log() in scheduler. If scheduler failed to schedue the pod, scheduler would send a failed scheduler event to pod. They are both confusing because the pod had already been successfully. /sig scheduler /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
Change:
} // optimization: avoid invoking the pod worker if no further changes are possible to the pod definition <del> if podWorkerTerminal { klog.V(4).Infof("Pod %q has completed, ignoring remaining sync work: %s", format.Pod(pod), syncType) </del> <ins> // (i.e. the pod has completed and its containers have been terminated) if podWorkerTerminal && containersTerminal { klog.V(4).InfoS("Pod has completed and its containers have been terminated, ignoring remaining sync work", "pod", klog.KObj(pod), "syncType", syncType) </ins> return }

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 pod exceeds we find that, The pod is correctly states with the reason but as you can see above the container state is still reported as What you expected to happen: Container state should be not because pod has exceeded How to reproduce it (as minimally and precisely as possible): Create the pod described above and wait till it exceeds listed . Then get the container status using, 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:
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 node
I would like to address this :) /assign
thanks.
Change:
"k8s.io/kubernetes/pkg/api/errors" "k8s.io/kubernetes/pkg/api/testapi" "k8s.io/kubernetes/pkg/api/unversioned" <ins> "k8s.io/kubernetes/pkg/client/restclient" </ins> "k8s.io/kubernetes/pkg/client/unversioned/fake" )

Discussion:
When users try to label/annotate multiple resources, we should tell them to add . Current output: Expected output:
and too
Instead of "--all is false", say "multiple resources were provided, but no label selector or --all flag specified"
Description updated based on suggestion
I think "resource(s) were provided, but no name, label selector, or --all flag specified" is better. I will send a pull request for this as my first PR.
Change:
if plugin, ok := inTreePlugins[pluginName]; ok { return plugin.GetInTreePluginName(), nil } <del> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %v", pluginName) </del> <ins> return "", fmt.Errorf("could not find In-Tree driver name for CSI plugin %s", pluginName) </ins> } // IsPVMigratable tests whether there is migration logic for the given Persistent Volume

Discussion:
I noticed that kube-controller-manager is consuming visible amount of CPU in completely idle 5k node cluster (~7 cores/s) while for comparison kube-apiserver was using much less that time. I fetched pprof and noticed that we are burning significant in metrics.(attachDetachStateCollector).CollectWithStability:! Going further, most of the cpu is used for fmt.Errorf for formatting v1.Volume in line 160: which is never actually used by the caller We do not use significant cpu for preparing error messages that are then ignored. pprof cluster with some pods and volumes. No response_ <details26.1 </details<detailsgke, any? </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
A trivial fix would be actually to change GetInTreePluginNameFromSpec to write only PV/Volume names instead of entire specs in error message.
/assign In scheduler we use this function to check if we can translate the in-tree PV to CSI, I think we also only need the name of the pv. I'll create a pr for this one line change.
/sig storage Instrumentation ?
Change:
--pod-manifest-path="${POD_MANIFEST_PATH}"  ${auth_args}  ${dns_args}  <del> ${net_plugin_dir_args}  </del> <ins> ${cni_conf_dir_args}  ${cni_bin_dir_args}  </ins> ${net_plugin_args}  ${container_runtime_endpoint_args}  ${image_service_endpoint_args} 

Discussion:
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: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.
Change:
"Time":           recent(maxStatsAge), "AvailableBytes": fsCapacityBounds, "CapacityBytes":  fsCapacityBounds, <del> // we assume we are not running tests on machines < 10tb of disk </del> <ins> // we assume we are not running tests on machines more than 10tb of disk </ins> "UsedBytes":  bounded(e2evolume.Kb, 10*e2evolume.Tb), "InodesFree": bounded(1e4, 1e8), "Inodes":     bounded(1e4, 1e8),

Discussion:
Which jobs are failing: ci-cri-containerd-node-e2e Which test(s) are failing: Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api Since when has it been failing: 2020 10-12 09:04 PDT Since Testgrid link: Reason for failure: Capability set incorrectly. CAPNETRAW should be NETRAW. I1013 18:39:19.058] Oct 13 18:10:51.403: INFO: At 2020-10-13 18:09:34 +0000 UTC - event for stats-busybox-0: {kubelet tmp-node-e2e--cos-81--1210-0} Failed: Error: failed to create containerd task: OCI runtime create failed: starting container process caused: unknown capability "CAPCAPNET_RAW": unknown Anything else we need to know: I have no idea where this is documented. It's a best guess.
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
it's a node_e2e test so /sig node
Seems like there's some dispute on who is doing the correct thing.
I would like to have a try.
please see discussion in
Change:
<del> [CHANGELOG/README.md](./CHANGELOG/README.md) </del> <ins> CHANGELOG/README.md </ins>  No newline at end of file

Discussion:
The change of this PR has resulted in the exception of the file. The file was originally a symbol file, but now other content has been , resulting in the exception of the file symbol. Rollback to the correct symbol file No response <details</details<details</details<details</details<details</details<details</details<details</details
/kind documentation
/triage accepted /priority important-soon /sig release
Change:
cmdNamespace, err := f.DefaultNamespace() cmdutil.CheckErr(err) mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).RequireNamespace(). ResourceTypeOrNameArgs(false, args...).

Discussion:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR
Change:
vm, err := as.getVirtualMachine(nodeName) if err != nil { // if host doesn't exist, no need to detach <del> klog.Warningf("azureDisk - cannot find node %s, skip detaching disk %s", nodeName, diskName) </del> <ins> klog.Warningf("azureDisk - cannot find node %s, skip detaching disk(%s, %s)", nodeName, diskName, diskURI) </ins> return nil }

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: add more logging in azure disk attach/detach 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: ): Kernel (e.g. ): Install tools: Others: /sig azure /assign
The issue message here doesn't say why a change was desired. The PR "Original logging is not clear when dealing with managed disk, since diskName is empty". That's more informative.