jiebi/CodeConvo huggingface dataset:
Change:
) const ( <del> dockerProcessName     = "docker" </del> <ins> dockerProcessName     = "dockerd" </ins> dockerPidFile         = "/var/run/docker.pid" containerdProcessName = "docker-containerd" containerdPidFile     = "/run/docker/libcontainerd/docker-containerd.pid"

Discussion:
This issue was reported in the Description The container manager used in kubelet checks for docker daemon process either via pidfile or process name. While the pidfile points to the docker daemon process PID, the dockerProcessName constant stores a docker cli name (docker) instead of docker daemon name (dockerd). Figure 30.1: Constants in file. Recommendation Correct the docker process name to dockerd. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of TOB-K8S-025 and it was finding 31 of the report. The vendor considers this issue Informational Severity. To view the original finding, begin on page 77 of the Environment: Kubernetes version: 1.13.4
/sig node /kind bug /remove-kind feature
/lgtm
lol, this is the issue. my bad!
Change:
TargetContainer string TTY             bool <ins> attachChanged         bool </ins> deprecatedInvocation  bool shareProcessedChanged bool

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: Using without specifying should modify existing container images without trying to create a new one. Instead it tries to create a new container and returns an error that isn't set: What you expected to happen: This command should change all container images to instead of returning an error. /sig cli /kind bug /priority important-soon
/assign /triage accepted
My kubernetes cluster version is 1.19.0,and i use kubectl-debug version 0.1.1 try to debug my pod,bug i got error: <img width="1470" alt="image" src="https://user-"Who one know about that
Change:
// Update actual state of world to reflect volume is globally mounted markDeviceMappedErr := actualStateOfWorld.MarkDeviceAsMounted( <del> volumeToMount.VolumeName) </del> <ins> volumeToMount.VolumeName, devicePath) </ins> if markDeviceMappedErr != nil { // On failure, return error. Caller will log and retry. return volumeToMount.GenerateErrorDetailed("MapVolume.MarkDeviceAsMounted failed", markDeviceMappedErr)

Discussion:
We fixed invalid device path in bunch of places via - but call still could use invalid device path. That check can sometimes use invalid path and hence can cause UnmountDevice operation to fails even though device has already been unmounted. /sig storage /sig openstack /assign
Actually this does not affect version 1.10 onwards. Not sure if 1.9 is still supported. I think I will close this for now. /close
I just noticed that 1.9 is still supported and hence it is probably worth fixing there for now.
How come the check can "sometimes" use invalid device path?
So on Cinder for example - call would return something like as attach device path. But if you see the linked PR(), will do a and use that device path for global mount. In general it is always a good idea to use device path returned by as single source of truth. This applies to something like EBS with NVMe too where device is discovered via call (but nvme disks aren't directly affected by this bug because returned device path on EBS is bogus).
So on EBS with NVMe for example - check will always fail (but still return success) because it will use something like as device path which does not actually exist on the node.
You said the issue only happens "sometimes". Can you clarify why it only happens occasionally?
doesn't the linked PR make it clear? detection based on the drive serial number (aka It's cinder ID) on the kubelet itself. As for why - Cinder sometimes returns wrong device path on call, I don't know. But it happens and we have worked around it.
Fixed by
Change:
creds := provider.Provide() <del> if len(creds) != len(result) { t.Errorf("Unexpected list: %v, expected length %d", creds, len(result)) </del> <ins> if len(creds) != len(result)+1 { t.Errorf("Unexpected list: %v, expected length %d", creds, len(result)+1) </ins> } for _, cred := range creds { <del> if cred.Username != "foo" { </del> <ins> if cred.Username != "" && cred.Username != "foo" { </ins> t.Errorf("expected 'foo' for username, saw: %v", cred.Username) } <del> if cred.Password != "bar" { </del> <ins> if cred.Password != "" && cred.Password != "bar" { </ins> t.Errorf("expected 'bar' for password, saw: %v", cred.Username) } }

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: Currently we cannot pull image from Azure Container Registry repo which provides anonymous pull access since when do image pull, it will always use service pincipal for .azurecr. 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 ): master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
}, } <del> doTestPlugin(t, volume.NewSpecFromPersistentVolume(vol, false)) </del> <ins> doTestPlugin(t, volume.NewSpecFromPersistentVolume(vol, false), "localhost:/somepath") </ins> } func TestPersistentClaimReadOnlyFlag(t *testing.T) {

Discussion:
In bare-metal IPv6 environment, any pod consuming storage resource is not able to run. The storage should be consumable, and the pod should become in status. Running the in a bare-metal IPv6 configurations. I have replaced the cloud-based storage resource with a mounted to a folder on my localhost. Steps alongside logs are below :- $kubectl get svc $kubectl describe svc nfs-server $kubectl describe pv nfs $kubectl get pod -w $kubectl get pod -w $kubectl describe pod nfs-busybox-6r96h I have built the master branch to make sure it was not fixed up to this moment.
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
/sig storage /tirage accepted /assign
Change:
Attach:          true, SELinuxRelabel:  true, SupportsMetrics: false, <ins> FSGroup:         true, </ins> } }

Discussion:
What happened: For some filesystems recursively applying an SELinux label through chcon or the GID permission is expensive (30 mins in some cases). There is better strategies for the recursive change and the call should be available through FLEX API. What you expected to happen: FLEX has a shell script call to label or set GID for a volume. Notes-- The fix should be backwards compatible.. If the shell call to perform the permission change is absent, then we fall back on the original method.
Change:
} defer func() { <del> podClient.Delete(config.Prefix+"-injector", nil) </del> <ins> podClient.Delete(podName, nil) </ins> }() injectPod, err := podClient.Create(injectPod)

Discussion:
Failing Job: These tests started flaking recently (they were consistently green for a long time): Mounted volume expand[Slow] Should verify mounted devices can be resized Volume expand [Slow] Verify if editing PVC allows resize Subpath [Volume type: gcePDPVC] should support restarting containers using file as subpath [Slow] Subpath [Volume type: gcePDPVC] should fail for new directories when readOnly specified in the volumeSource Subpath [Volume type: gcePDPVC] should fail if subpath with backstepping is outside the volume [Slow] Volumes PD should be mountable with ext4 Affected runs: https://k8s- https://k8s- https://k8s- /kind bug /sig storage /priority important-soon /milestone v1.12 /cc - Could you PTAL or delegate? Thanks.
Volume expansion tests have been fixed by
/assign can you investigate the remaining failures?
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 4 days, the issue will be moved out of the v1.12 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Reopening this issue, as a bunch of storage-related e2es started flaking in our large-scale jobs recently: https://k8s- https://k8s- /reopen
I think the latest failures are caused by gce API rate limiting: /assign
It seems to only be failing on scalability test suites. I wonder if it's due to some different cidr configuration
/sig scalability
/kind failing-test
/status approved-for-milestone Friendly ping. This is affecting release-blocking scalability job.
hey what needs to be done here? by whom?
Could you comment on what needs to be done here and by whom?
can you guys take a look at the API quota issue?

This is happening consistently in the scale test environment
as Code Freeze is today, this needs to be of priority . Please triage! cc
It looks like the latest run on 9/1 has passed.
Marking closed as the fixes have been merged and the test runs are now passing /close
Closing this issue. <detailsIn response to : Marking closed as the fixes have been merged and the test runs are now passing /close 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:
params+=("--agent-service-account=konnectivity-agent") params+=("--kubeconfig=/etc/srv/kubernetes/konnectivity-server/kubeconfig") params+=("--authentication-audience=system:konnectivity-server") <ins> params+=("--kubeconfig-qps=75") params+=("--kubeconfig-burst=150") </ins> konnectivity_args="" for param in "${params[@]}"; do konnectivity_args+=", "${param}""

Discussion:
After the gce-master-scale-performance started failing with errors like: https://k8s- In a sample run I see a lot of errors like: in konnectivity-server logs: Looks like we have to increase QPS limit for konnectivity-server, do we have a flag (kube-env?) for that? /cc /assign
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 cloud-provider
/priority critical-urgent
We may need to re-open this, if there are still uncovered problems (or if we need to re-tune) after watching next test runs.
Wow, thanks a lot for such a rapid fix. Much appreciated!
Change:
-v "${REPO_DIR}":/go/src/k8s.io/kubernetes  -v "${KUBE_JUNIT_REPORT_DIR}":/workspace/artifacts  --env REPO_DIR="${REPO_DIR}"  <del> -i gcr.io/google_containers/kubekins-test:0.5  </del> <ins> -i gcr.io/google_containers/kubekins-test:0.6  </ins> bash -c "cd kubernetes && ./hack/jenkins/test-dockerized.sh"

Discussion:
It seems like an issue similar to the problem with API server. I'll extend the timeout in the similar fashion. cc
Extending timeout didn't help. It's probably something else.
cc
I think the logs make it pretty clear what went wrong: or does one of you have time to fix this?
The Jenkins docker test image probably needs netcat to be installed. Should be an easy fix; I can take this.
Thanks!
Ugh... neverending story.
This seems like a different problem.
Oh, I see, this actually is the same, but harder: I think the most obvious thing to do is to let kubectl select the port and report back?
reports more occurances. Netcat somehow is no longer installed?
those two are older builds, using , which didn't have netcat yet.
ah thanks!
are you still working on this? Would you like me to take it?
I'm not right now, sorry, feel free to take it.
Change:
delete(pk.podTerminationMap, uid) } <del> // checkAndMarkPodPendingTerminationByPod checks to see if the pod is being // killed and returns true if it is, otherwise the pod is added to the map and // returns false func (pk *podKillerWithChannel) checkAndMarkPodPendingTerminationByPod(podPair *kubecontainer.PodPair) bool { </del> <ins> // KillPod sends pod killing request to the killer after marks the pod // unless the given pod has been marked to be killed func (pk *podKillerWithChannel) KillPod(podPair *kubecontainer.PodPair) { </ins> pk.podKillingLock.Lock() defer pk.podKillingLock.Unlock() var apiPodExists bool

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: Right after calling , returns false even the pod is not killed yet. What you expected to happen: In kubelet, after is complete, the pod should be pending termination or be killed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Related to 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 /assign
Change:
} return rows, nil } <ins> func printResourceQuota(resourceQuota *api.ResourceQuota, options printers.PrintOptions) ([]metav1beta1.TableRow, error) { row := metav1beta1.TableRow{ Object: runtime.RawExtension{Object: resourceQuota}, } resources := make([]api.ResourceName, 0, len(resourceQuota.Status.Hard)) for resource := range resourceQuota.Status.Hard { resources = append(resources, resource) } sort.Sort(SortableResourceNames(resources)) requestColumn := bytes.NewBuffer([]byte{}) limitColumn := bytes.NewBuffer([]byte{}) for i := range resources { w := requestColumn resource := resources[i] usedQuantity := resourceQuota.Status.Used[resource] hardQuantity := resourceQuota.Status.Hard[resource] // use limitColumn writer if a resource name prefixed with "limits" is found if pieces := strings.Split(resource.String(), "."); len(pieces) > 1 && pieces[0] == "limits" { w = limitColumn } fmt.Fprintf(w, "%s: %s/%s, ", resource, usedQuantity.String(), hardQuantity.String()) } age := translateTimestampSince(resourceQuota.CreationTimestamp) row.Cells = append(row.Cells, resourceQuota.Name, age, strings.TrimSuffix(requestColumn.String(), ", "), strings.TrimSuffix(limitColumn.String(), ", ")) return []metav1beta1.TableRow{row}, nil } func printResourceQuotaList(list *api.ResourceQuotaList, options printers.PrintOptions) ([]metav1beta1.TableRow, error) { rows := make([]metav1beta1.TableRow, 0, len(list.Items)) for i := range list.Items { r, err := printResourceQuota(&list.Items[i], options) if err != nil { return nil, err } rows = append(rows, r...) } return rows, nil } </ins>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature isn't very useful as it only shows the name and age of the resourcequota resource. It'd be nice if it also shows the current/allocated usage for each, like this: Each resourcequota summary is of the format: . I think it would be a useful feature. I wouldn't mind taking a crack at implementing it if it's deemed worth by the maintainers. Thanks.
/sig cli
/assign code-sleuth
GitHub didn't allow me to assign the following users: code-sleuth. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : /assign code-sleuth 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 juanvallejo
Change:
nodeSnapshot.generation = cache.headNode.info.Generation } <del> if len(nodeSnapshot.nodeInfoMap) > len(cache.nodes) { </del> <ins> // Comparing to pods in nodeTree. // Deleted nodes get removed from the tree, but they might remain in the nodes map // if they still have non-deleted Pods. if len(nodeSnapshot.nodeInfoMap) > cache.nodeTree.numNodes { </ins> cache.removeDeletedNodesFromSnapshot(nodeSnapshot) updateAllLists = true }

Discussion:
/sig scheduling What happened: reverted an old behavior to ensure Pod information is not lost when Nodes are recreated without its Pods getting recreated. A ghost Pod is kep in The problem is that we rely in this map for determining deleted Nodes when updating the snapshot in . The good thing is that the nodeinfo's are cloned into the snapshot, so we shouldn't have nil pointer accesses. But we might lose a few cycles trying to schedule on nodes that are deleted How to reproduce it (as minimally and precisely as possible): a node with a few pods. node without deleting pods. Result: The snapshot still has the node. Environment: Kubernetes version (use ): 1.18+
/assign
It actually produces the error: which would cause failed scheduling cycles (the map is not recreated, only the lists).
Change:
requestGB := int(volume.RoundUpSize(requestBytes, 1024*1024*1024)) volumeOptions := &aws.VolumeOptions{ CapacityGB: requestGB, <del> Tags:       &tags, </del> <ins> Tags:       tags, </ins> } name, err := cloud.CreateDisk(volumeOptions)

Discussion:
We should tag EBS volumes created by k8s with our tags, just like we (should) tag everything else we create/own.
Is there any documentation yet on automatic EBS volume creation?
from a user perspective, they are not AWS specific. That said, I don't know that we have clear user-facing docs. Here's an example though, from my (very) WIP Ubernetes-Lite docs: ... The PV is also tagged with the zone & region is is in (us-central1-a): Create a pod that uses the PVC:
It doesn't seem to cleanup the volume when the PV is deleted... probably intended behavior. Any way to tell it to automatically delete the volume on PV delete?
- I'm not sure about foo - hopefully that'll be resolved with docs. I think the failure to delete the volume is actually pretty important. Do you want to open an issue? It's not AWS specific (and this particular issue was auto-closed when the PR merged)
yeah I will open an issue later today. Issue seems to still be happening - the PV is never deleted. On Sat, Mar 12, 2016, 6:24 AM Justin Santa Barbara wrote:
Change:
if err = testutils.WaitForPodToSchedule(testCtx.ClientSet, pod); err != nil { t.Errorf("Expected the pod to be scheduled. error: %v", err) } <del> if filterPlugin.numFilterCalled != tt.expectFilterNumCalled { t.Errorf("Expected the filter plugin to be called %v times, but got %v.", tt.expectFilterNumCalled, filterPlugin.numFilterCalled) </del> <ins> if numFilterCalled := atomic.LoadInt32(&filterPlugin.numFilterCalled); numFilterCalled != tt.expectFilterNumCalled { t.Errorf("Expected the filter plugin to be called %v times, but got %v.", tt.expectFilterNumCalled, numFilterCalled) </ins> } if numScoreCalled := atomic.LoadInt32(&scorePlugin.numScoreCalled); numScoreCalled != tt.expectScoreNumCalled { t.Errorf("Expected the score plugin to be called %v times, but got %v.", tt.expectScoreNumCalled, numScoreCalled)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: integration-master Which test(s) are flaking: TestPostFilterPlugin Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig testing
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 /remove-sig testing
/assign
Change:
func createPDWithRetry() (string, error) { newDiskName := "" var err error <del> for start := time.Now(); time.Since(start) < 180*time.Second; time.Sleep(5 * time.Second) { </del> <ins> for start := time.Now(); time.Since(start) < gcePDRetryTimeout; time.Sleep(gcePDRetryPollTime) { </ins> if newDiskName, err = createPD(); err != nil { framework.Logf("Couldn't create a new PD. Sleeping 5 seconds (%v)", err) continue

Discussion:
For: "Pod Disks should schedule a pod w/ a RW PD, remove it, then schedule it on another host" "Pod Disks should schedule a pod w/ a readonly PD on two hosts, then remove both." (this is not happening on v1.3 master with v1.1 nodes, nor with v1.2 tests against a v1.3 cluster) View logs and artifacts at
Mind taking a look? You should be able to repro by turning up a v1.3 cluster and running v1.1 tests against it.
for your queue
I found the cause of the test failure. The following are the main steps in the test host0Pod, and wait for it running a file to the host0Pod, and then delete it host1Pod, and waiting for it running the file from host1Pod, and then delete it disk with deletePDWithRetry() function, which has 3 minutes timeout defer() function, clean up test environment, and also run deletePDWithRetry() again just in case The problem arises from step 5. In the above test, deletePDWithRetry tried to delete PD every 5 second, but failed in 3 minutes. After it exits retry loop, it failed for the expectNoError(err, "Error deleting PD") in this function. Although it deleted the PD successfully right after this during the clean up phase (step 6). So the main issue for this test failure is the timeout is a little bit short. To fix it issue, we can either increase the timeout, or not fail when calling deletePDWithRetry for the first time. We can fail it if it cannot delete it after calling deletePDWIthRetry second time in step 6. The following is the retry loop and error code in the deletePDWIthRetry(). In current 1.3 version, we only call deletePDWithRetry once in defer() function during clean up. I think to be safe we should increase timeout to 5 minutes, and set it in the constance instead of coding it directly inside of the function.
So two options to fix this: port test fixes from main branch to the 1.1 branch to make the test more robust against delays. for to be merged, which will decrease the time it takes for a volume to be detached and therefore how long it takes to be deleted.