jiebi/CodeConvo huggingface dataset:
Change:
return status } <del> cs.Lock() </del> <ins> // multiple goroutines call `Filter` on different nodes simultaneously and the `CycleState` may be duplicated, so we must use a local lock here state.Lock() </ins> state.podVolumesByNode[node.Name] = podVolumes <del> cs.Unlock() </del> <ins> state.Unlock() </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: during phase from the plugin when the is updated: What you expected to happen: Not crash. How to reproduce it (as minimally and precisely as possible): I am suspecting that the issue is in the naive implementation of the 's method: Most likely the is cloned during filter phase, e.g. in the called during in the : ... and when is cloned during filtering, new mutex is created, but is not cloned properly, this mean that potentially there are two or more different mutexes protecting the same map from writes. Anything else we need to know?: I think potential solution is to have mutex in the or change the 's . Environment: Kubernetes version (use ): 1.19.0 Cloud provider or hardware configuration: not relevant OS (e.g: ): not relevant Kernel (e.g. ): not relevant Install tools: not relevant Network plugin and version (if this is a network-related bug): not relevant Others: not relevant /sig scheduling
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 scheduling
It looks like relevant code is from and mutex per was considered intially. CC
IIUC, the may (edit: if the node has nominated pods) be duplicated in for every node before passing to extension point. So we cann't rely on 's lock to prevent the state from being modified concurrently. Am I right?
I may have given an incorrect analysis as VolumeBinding's plugin-specific state are always using the same pointer, sorry for the confusion. I removed the confusing comments. It's actually different from what was discussed in . Your and 's analysis make more sense to me.

For nodes that have nominated nodes (cloned CycleState) or not (original CycleState), the original mutex may not be able to protect the CycleState: I will take another look tomorrow.
can you please post the actual core dump, the description in the original comment doesn't seem complete. If the "concurrent map" fatal error is indeed happening at , then it means we are operating on two different CycleStates instances at the same time, which may happen when adding nominated pods () Using the CycleState lock to synchronize access to the plugin's state in the map is not proper, the plugin state itself should have its private lock, this is certainly a bug.
/cc
Change:
"http://ftp.us.debian.org/debian/pool/main/b/busybox/busybox-static_1.22.0-19+b3_amd64.deb", "https://storage.googleapis.com/kubernetes-release/debs/busybox-static_1.22.0-19+b3_amd64.deb", ), <del> ( "libc_deb", "372aac4a9ce9dbb26a08de0b9c41b0500ba019430295d29f39566483f5f32732", "http://ftp.us.debian.org/debian/pool/main/g/glibc/libc6_2.24-10_amd64.deb", "https://storage.googleapis.com/kubernetes-release/debs/libc6_2.24-10_amd64.deb", ), ( "iptables_deb", "7747388a97ba71fede302d70361c81d486770a2024185514c18b5d8eab6aaf4e", "http://ftp.us.debian.org/debian/pool/main/i/iptables/iptables_1.4.21-2+b1_amd64.deb", "https://storage.googleapis.com/kubernetes-release/debs/iptables_1.4.21-2+b1_amd64.deb", ), ( "libnetlink_deb", "5d486022cd9e047e9afbb1617cf4519c0decfc3d2c1fad7e7fe5604943dbbf37", "http://ftp.us.debian.org/debian/pool/main/libn/libnfnetlink/libnfnetlink0_1.0.1-3_amd64.deb", "https://storage.googleapis.com/kubernetes-release/debs/libnfnetlink0_1.0.1-3_amd64.deb", ), ( "libxtables_deb", "6783f316af4cbf3ada8b9a2b7bb5f53a87c0c2575c1903ce371fdbd45d3626c6", "http://ftp.us.debian.org/debian/pool/main/i/iptables/libxtables10_1.4.21-2+b1_amd64.deb", "https://storage.googleapis.com/kubernetes-release/debs/libxtables10_1.4.21-2+b1_amd64.deb", ), ( "iproute2_deb", "3ce9cb1d03a2a1359cbdd4f863b15d0c906096bf713e8eb688149da2f4e350bc", "http://ftp.us.debian.org/debian/pool/main/i/iproute2/iproute_3.16.0-2_all.deb", "https://storage.googleapis.com/kubernetes-release/debs/iproute_3.16.0-2_all.deb", ), </del> ) [http_file(

Discussion:
BUG REPORT Kubernetes version 2 Environment: Install tools: What happened: The code in takes care to supply the flag so it will wait on a lock to avoid interference between multiple processes modifying the table. If you read the source you discover it does this by creating a file . However, when is running in a container, is in a local filesystem, so it is not able to lock against processes running on the host or in other containers. And before you decide that the answer is to mount from the host, look at all the issues around leaking netns, e.g. Credit for pointing this out to me. Credit for pointing out locking functionality was to a few months back
Ironically, this is caused by a bugfix that moved to file-based locking. Previously, iptables would lock by reserving an abstract unix socket, which is tied to the network namespace.
Some discussion also in and following comments.
I experimented with this: but it didn't work on CoreOS, as the host wasn't using a version of iptables that used the file lock yet. Just ended up creating a directory call
I guess I should file this as an issue against kubeadm and any of the other sources of kube-proxy container config.
/assign
Should we leave this open (waiting for ... ?)
Waiting for I guess... (which I'm reviewing now)
i think this should not be marked as complete until the kubeadm fixes are in.
/reopen
/close fix in
Change:
MaxAllowedFluentdRestarts int } <del> func (entry logEntry) getLogEntryNumber() (int, bool) { submatch := logEntryMessageRegex.FindStringSubmatch(entry.Payload) if submatch == nil || len(submatch) < 2 { return 0, false } lineNumber, err := strconv.Atoi(submatch[1]) return lineNumber, err == nil </del> <ins> // Type to track the progress of logs generating pod type loggingPod struct { // Name equals to the pod name and the container name. Name string // NodeName is the name of the node this pod will be // assigned to. Can be empty. NodeName string // Occurrences is a cache of ingested and read entries. Occurrences map[int]logEntry // ExpectedLinesNumber is the number of lines that are // expected to be ingested from this pod. ExpectedLinesNumber int // RunDuration is how long the pod will live. RunDuration time.Duration </ins> } <del> func createLoggingPod(f *framework.Framework, podName string, nodeName string, totalLines int, loggingDuration time.Duration) *loggingPod { framework.Logf("Starting pod %s", podName) createLogsGeneratorPod(f, podName, nodeName, totalLines, loggingDuration) </del> <ins> func newLoggingPod(podName string, nodeName string, totalLines int, loggingDuration time.Duration) *loggingPod { </ins> return &loggingPod{ Name:                podName, <ins> NodeName:            nodeName, </ins> Occurrences:         make(map[int]logEntry), ExpectedLinesNumber: totalLines, <ins> RunDuration:         loggingDuration, </ins> } } <del> func createLogsGeneratorPod(f *framework.Framework, podName string, nodeName string, linesCount int, duration time.Duration) { </del> <ins> func (p *loggingPod) Start(f *framework.Framework) { framework.Logf("Starting pod %s", p.Name) </ins> f.PodClient().Create(&api_v1.Pod{ ObjectMeta: meta_v1.ObjectMeta{ <del> Name: podName, </del> <ins> Name: p.Name, </ins> }, Spec: api_v1.PodSpec{ RestartPolicy: api_v1.RestartPolicyNever,

Discussion:
Pods should be run in parallel with checking the logs from the backend to fit into the timeout.
Change:
FailureThreshold:    1, } pod := livenessPodSpec(f.Namespace.Name, nil, livenessProbe) <del> RunLivenessTest(f, pod, 5, time.Minute*5) </del> <ins> // ~2 minutes backoff timeouts + 4 minutes defaultObservationTimeout + 2 minutes for each pod restart RunLivenessTest(f, pod, 5, 2*time.Minute+defaultObservationTimeout+4*2*time.Minute) </ins> }) /*

Discussion:
In </span /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node I believe the issue here is that the test is trying to get 5 restarts, but if we don't start the loop until after a few failures have occurred we start getting caught up in exponential backoff. The 6th backoff iteration is a 2m30s wait (i believe), so we exceed the default timeout of 5m for the test. We may need to change the test so that we are watching for pod status updates and catch the first one. HOWEVER - there's also some head of line blocking in pod status manager updates that I suspect might result in updates getting delayed, leading to timeout. Either way, the test has too little margin with exponential failure backoff to be reliable, and needs to be improved.
/triage accepted /assign
Change:
ready = true } } <del> if !ready { </del> <ins> // Failed pods in this context generally mean that they have been // double scheduled onto a node, but then failed a constraint check. if pod.Status.Phase == api.PodFailed { glog.Warningf("Pod has failed: %v", pod) } if !ready && pod.Status.Phase != api.PodFailed { </ins> notready = append(notready, pod.Name) } }

Discussion:
https://k8s- Failed: [] Cluster size autoscaling [Slow] should increase cluster size if pods are pending due to host port conflict [Feature:ClusterSizeAutoscalingScaleUp] {Kubernetes e2e suite} Previous issues for this test:
The trouble here is that the pods are in , from the controller-manager logs:
I believe the problem here is that pods are sneaking onto machines and then not starting due to constraints (host port unavailable) but these pods count as which causes the test to go forever. I'm going to switch the test to only consider pods.
Change:
package volumepathhandler import ( <del> "bufio" </del> "errors" "fmt" <ins> "io/ioutil" </ins> "os" "os/exec" "path/filepath"

Discussion:
I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
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
/remove-lifecycle rotten
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
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
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/help
This request has been marked as needing help from a contributor. 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 : /help </details
Change:
break } if !initializing { <ins> restarts = 0 </ins> for i := len(pod.Status.ContainerStatuses) - 1; i >= 0; i-- { container := pod.Status.ContainerStatuses[i]

Discussion:
The output looks like below: What is expected behavior? Does restart counter should increase when init containers are failing? Does restart counter should be reseted when InitContainer will start work and normal containers start? cc
Restarts are tracked per container - I'd be concerned that the restarts the user is concerned with don't map exactly to the init container restarts, although knowing how many attempts to init have been made are useful. Since init containers are processed serially, when an init container passes, do we reset the restart count to zero? I think we could show the current init container restart count (if pod is in init) in this field. But once the init container succeeds it has to drop back to zero.
For normal containers field shows the sum of from containers status. I think for init containers as we know which container is running (when is merged) we can show restart count for current init container. For normal containers behavior should not change. So it would look like these: First init container is failing Second init container is failing Normal container is failing For better readability we may also add word like in status: Second init container is failing What do you think?
Yeah, although I don't know that we need the Init prefix in the status. I think users can reasonably be expected to infer that RESTARTS is subordinate to STATUS. The init prefix makes it harder to read without adding a ton. , Łukasz Oleś wrote:
Ah, I messed up. shows status of normal containers. in Status shows status of init containers: I think this part should be always showed. So it will look like these: What do you think?
Ok, I decided to use the same approach as for normal containers. RESTARTS just shows sum of all init containers restarts.
Fix is merged
Change:
name                    string pod                     *v1.Pod enableSidecarContainers bool <del> wantStatus              *framework.Status </del> <ins> wantPreFilterStatus     *framework.Status </ins> }{ { name: "allow pod without restartable init containers if sidecar containers is disabled", pod:  newPod(), }, { <del> name:       "not allow pod with restartable init containers if sidecar containers is disabled", pod:        newPodWithRestartableInitContainers(), wantStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, "Pod has a restartable init container and the SidecarContainers feature is disabled"), </del> <ins> name:                "not allow pod with restartable init containers if sidecar containers is disabled", pod:                 newPodWithRestartableInitContainers(), wantPreFilterStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, "Pod has a restartable init container and the SidecarContainers feature is disabled"), </ins> }, { name:                    "allow pod without restartable init containers if sidecar containers is enabled",

Discussion:
/kind feature /sig scheduling Filter will return for all nodes when is and is . This can be done is PreFilter. Executing this code in the filter will cause it to be repeated tens of times, with the worst-case scenario being repeated thousands of times. Maybe we should move this to PreFilter like:
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
Sounds reasonable to me :) I think you can go ahead and file a pr for this.
/assign
Sure.
Hi, If you don't mind, I can try to do this.
/assign
Change:
} return clone } <ins> // Filter takes a condition set expressed as map[string]sets.String and returns a new // ResourceDeviceInstances with only the devices matching the condition set. func (rdev ResourceDeviceInstances) Filter(cond map[string]sets.String) ResourceDeviceInstances { filtered := NewResourceDeviceInstances() for resourceName, filterIDs := range cond { if _, exists := rdev[resourceName]; !exists { continue } filtered[resourceName] = DeviceInstances{} for instanceID, instance := range rdev[resourceName] { if filterIDs.Has(instanceID) { filtered[resourceName][instanceID] = instance } } } return filtered } </ins>

Discussion:
When calling GetAllocatableDevices, the API returns all the registered devices, regardless of their health status. Thing is, the - and in general doesn't make much sense to report as allocatable Unhealthy devices, as is also documented in the (see last paragraph) The API should not report unhealthy device. This means the reported device set can potentially change across multiple invocations of the API, as . a kube = 1.21 environment, enable the feature gate any device plugin - including sample device plugin sure 1+ devices are reported unhealthy the podresources GetAllocatableResources API, observe the unhealthy device is reported in the return value. N/A Kubernetes version (use ): 1.21 and beyond Cloud provider or hardware configuration: not relevant OS (e.g: ): any Kernel (e.g. ): not relevant Install tools: not relevant Network plugin and version (if this is a network-related bug): not relevant Others: not relevant
/sig node
/triage accepted
Change:
} } <ins> // Container information is used in adjusting OOM scores, adding ndots and getting the logPath. containerInfo, err := dm.client.InspectContainer(id.ID) if err != nil { return kubecontainer.ContainerID{}, fmt.Errorf("InspectContainer: %v", err) } </ins> // Create a symbolic link to the Docker container log file using a name which captures the // full pod name, the container name and the Docker container ID. Cluster level logging will // capture these symbolic filenames which can be used for search terms in Elasticsearch or for // labels for Cloud Logging. <del> containerLogFile := path.Join(dm.dockerRoot, "containers", id.ID, fmt.Sprintf("%s-json.log", id.ID)) </del> <ins> containerLogFile := containerInfo.LogPath </ins> symlinkFile := LogSymlink(dm.containerLogsDir, kubecontainer.GetPodFullName(pod), container.Name, id.ID) if err = dm.os.Symlink(containerLogFile, symlinkFile); err != nil { glog.Errorf("Failed to create symbolic link to the log file of pod %q container %q: %v", format.Pod(pod), container.Name, err) } <del> // Container information is used in adjusting OOM scores and adding ndots. containerInfo, err := dm.client.InspectContainer(id.ID) if err != nil { return kubecontainer.ContainerID{}, fmt.Errorf("InspectContainer: %v", err) } </del> // Check if current docker version is higher than 1.10. Otherwise, we have to apply OOMScoreAdj instead of using docker API. // TODO: Remove this logic after we stop supporting docker version < 1.10. if err = dm.applyOOMScoreAdjIfNeeded(pod, container, containerInfo); err != nil {

Discussion:
After starting a container, Kubernetes places a symlink to the container's log file in . Unfortunately, rather than querying Docker for the , . This means that any change upstream in the path or filename that Docker uses to store its logs (e.g. to so that a file name transition would be a workable solution for docker/docker) would result in broken symlinks being put in place. It would be a better idea to query for the , potentially by doing something like this: This would allow Docker to put the log files anywhere and have symlinks put in the right place.
I will start work on this one, PR coming soon.
Change:
return nil, 0, fmt.Errorf("error creating volume %v", err) } glog.V(1).Infof("glusterfs: volume with size: %d and name: %s created", volume.Size, volume.Name) <del> dynamicHostIps, err := getClusterNodes(cli, volume.Cluster) </del> <ins> dynamicHostIps, err := p.GetClusterNodes(cli, volume.Cluster) </ins> if err != nil { glog.Errorf("glusterfs: error [%v] when getting cluster nodes for volume %s", err, volume) return nil, 0, fmt.Errorf("error [%v] when getting cluster nodes for volume %s", err, volume)

Discussion:
several operations to the glusterfs mount operation that nodes are not permitted to perform: looks up arbitrary secrets based on storage class parameters. this will not succeed, as the node authorizer will only allow nodes access to secrets referenced by pods or persistent volumes used by the node attempts to create a service and endpoint using the node's API client. nodes do not have permission to create arbitrary endpoints and services. For both of those reasons, that recreate operation will fail when attempted from the node. The recreate operation should probably move to one of the storage-related controllers (provisioner or attach/detach) cc
Marking this with 1.7 milestone until we have a better idea of whether this is blocking or not for the 1.7 release.
CC Is the endpoint originally created by the user or by the volume plugin creating/deleting Endpoint objects? In addition to the concerns raised, having a volume create new API objects seems like a bad idea (abstraction layer violation?).
From on Slack: Unless there is justification otherwise, I will roll back the PR on Monday.
cc/
revert button doesn't work, have to do it manually
Revert PR is approved and awaiting merge (). Once that merges this issue can be closed.
Opened an E2E pr to catch this kind of behavior in the future. WIP, still exploring a method to reproduce and catch the behavior.
Change:
} func isNotFound(err error) bool { <del> e, ok := err.(*gophercloud.ErrUnexpectedResponseCode) return ok && e.Actual == http.StatusNotFound </del> <ins> if _, ok := err.(gophercloud.ErrDefault404); ok { return true } if errCode, ok := err.(gophercloud.ErrUnexpectedResponseCode); ok { if errCode.Actual == http.StatusNotFound { return true } } return false </ins> } // Zones indicates that we support zones

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: when using cloud controller manager, function is not working correctly. Common function is not return correct value if instance is deleted from cloudprovider. What you expected to happen: I except that code should end to row if node is deleted from cloudprovider. How to reproduce it (as minimally and precisely as possible): kubernetes cluster to openstack cloudprovider using cloud controller manager debug print after this row cluster is up and running, delete one node from openstack and see the cloud controller log file result is If this works correctly it should return nil as error, from this row But now the code is not going there because is not working correctly. I debugged this function, and when instance is deleted from openstack this row variable e is and ok is . So it is not working as should. Anything else we need to know?: I am thinking that is this working correcly in any other place currently in openstack cloudprovider. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: openstack mitaka cc as you are author of this function. I am thinking could we just fix that using dirty way where ErrResNotFound is constant
/sig openstack
is this now fixed with the changes referenced?
yes all fixed this can be closed