jiebi/CodeConvo huggingface dataset:
Code change:
assert.Equal(t, test.output, output) } } <del> func TestPodResourcesAreReclaimed(t *testing.T) { type args struct { pod           *v1.Pod status        v1.PodStatus runtimeStatus kubecontainer.PodStatus } tests := []struct { name string args args want bool }{ { "pod with running containers", args{ pod: &v1.Pod{}, status: v1.PodStatus{ ContainerStatuses: []v1.ContainerStatus{ runningState("containerA"), runningState("containerB"), }, }, }, false, }, { "pod with containers in runtime cache", args{ pod:    &v1.Pod{}, status: v1.PodStatus{}, runtimeStatus: kubecontainer.PodStatus{ ContainerStatuses: []*kubecontainer.ContainerStatus{ {}, }, }, }, false, }, { "pod with sandbox present", args{ pod:    &v1.Pod{}, status: v1.PodStatus{}, runtimeStatus: kubecontainer.PodStatus{ SandboxStatuses: []*runtimeapi.PodSandboxStatus{ {}, }, }, }, false, }, } testKubelet := newTestKubelet(t, false) defer testKubelet.Cleanup() kl := testKubelet.kubelet for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { testKubelet.fakeRuntime.PodStatus = tt.args.runtimeStatus if got := kl.PodResourcesAreReclaimed(tt.args.pod, tt.args.status); got != tt.want { t.Errorf("PodResourcesAreReclaimed() = %v, want %v", got, tt.want) } }) } } </del>

Related discussion:
text: </details
/cc
will increase the time for deletion of pod and it should be expected because currently pod is deleted from apiserver before removing the sandbox container but after this fix pod will be deleted from the apiserver only after deleting the sandbox container.
/remove-sig scheduling doesn't affect scheduling running time at all.
Yeah, is almost definitely the culprit. Last time we changed that code path, it also caused a regression. The degradation in performance is expected, but a 5x slowdown is definitely larger than it should be.
do we know if that's because the status used by the path is stale, or if removing sandboxes is actually that slow?
if there's not a quick fix, should we revert and bring it back in once the root issue is understood?
I think a revert is appropriate in this case.
ok, I'll open it
open at
I agree with that 5x is something which shouldn't happen and i can take a look on why thats happening and that might require changing the way how the sandbox is currently deleted which is only during GC.
Code change:
echo -n Attempt "$(($attempt+1))" to check for SSH to master local output local ok=1 <del> output=$(ssh -oStrictHostKeyChecking=no -i "${AWS_SSH_KEY}" ubuntu@${KUBE_MASTER_IP} uptime 2> $LOG) || ok=0 </del> <ins> output=$(ssh -oStrictHostKeyChecking=no -i "${AWS_SSH_KEY}" ${SSH_USER}@${KUBE_MASTER_IP} uptime 2> $LOG) || ok=0 </ins> if [[ ${ok} == 0 ]]; then if (( attempt > 30 )); then echo

Related discussion:
text: <!-- 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?: What happened: I visited the Kubernetes 1.11 release blog post and clicked on the link to the article on resizing persistent volumes. The server returned a 404. What you expected to happen: I expected to navigate to the article on resizing persistent volumes in Kubernetes. How to reproduce it (as minimally and precisely as possible): Visit the release announcement blog post (), scroll down to the "4 Day Features Blog Series" section, and click on the link to the article on resizing persistent volumes. Anything else we need to know?: The link currently points to: The correct link is: Environment: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
Reiterating the mentions to trigger a notification: <detailsIn response to : <!-- This form is for bug reports and feature requests ONLY! --/kind bug /kind feature What happened: I visited the Kubernetes 1.11 release blog post and clicked on the link to the article on resizing persistent volumes. The server returned a 404. I expected to navigate to the article on resizing persistent volumes in Kubernetes. Visit the release announcement blog post (), scroll down to the "4 Day Features Blog Series" section, and click on the link to the article on resizing persistent volumes. The link currently points to: The correct link is: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A 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
It should be reported to kubernetes/website, but doesn't matter.
Code change:
// Enable swagger api on master. components.KubeMaster.InstallSwaggerAPI() cluster := clientcmdapi.NewCluster() cluster.Server = components.ApiServer.URL cluster.InsecureSkipTLSVerify = true <ins> cfg.Contexts = map[string]*clientcmdapi.Context{"test": ctx} cfg.CurrentContext = "test" </ins> overrides := clientcmd.ConfigOverrides{ <del> ClusterInfo:    *cluster, Context:        *ctx, CurrentContext: "test", </del> <ins> ClusterInfo: *cluster, </ins> } cmdConfig := clientcmd.NewNonInteractiveClientConfig(*cfg, "test", &overrides, nil) factory := util.NewFactory(cmdConfig)

Related discussion:
text: In 1.1, if you specify "current-context: i-do-not-exist" in a kubeconfig, and there's no matching context by that name in the contexts, kubelet silently uses what I assume is either an empty or a default configuration. This can result in hilarity like wondering why your kubelet isn't using the TLS settings you provided, and spending several hours debugging the whole stack only to discover that you typo'd current-context :). It would be better if kubelet and other users of errored out on such a misconfiguration, to make the failure obvious and trivial.
cc
I think kubelet silently uses an empty configuration. Guess we should give a waring here.
Did you start to work on this?
Below is related code: can you confirm this? Besides if we want to log a waring in kubelet, we may need to get in kubelet.
cc
cc
I believe kubelet already uses . Adding a check in that current context exists if specified sounds like the right approach.
Are there any backwards compatibility implications here? would this break users who have existing configs (that fallback to default namespace)? , Jeff Lowdermilk wrote:
I think kubelet directly use not . Also already checks whether the user-specified current context exists, the problem is that if not exist, we just skip. We need to do something if the current context not exist, like log a warning.
Erroring on a specified and bad seems reasonable. If it is not specified and there's only one option, I don't think we should fail.
yeap, the case is that user specify the but not exist, in such case we should just fail.
If no one is working on this I can take it.
I think this is the root cause. Basically we should error on this not exist context. If you have extra bandwidth, please go ahead :)
This is related to - the defaulting is what allows us to continue. When that merges, only kubectl will have the "use localhost:8080" as defaulting.
Code change:
klog.Errorf("Unsupported protocol type: %s", protocol) } if nodePortLocalSet != nil { <del> if valid := nodePortLocalSet.validateEntry(entry); !valid { klog.Errorf("%s", fmt.Sprintf(EntryInvalidErr, entry, nodePortLocalSet.Name)) </del> <ins> entryInvalidErr := false for _, entry := range entries { if valid := nodePortLocalSet.validateEntry(entry); !valid { klog.Errorf("%s", fmt.Sprintf(EntryInvalidErr, entry, nodePortLocalSet.Name)) entryInvalidErr = true break } nodePortLocalSet.activeEntries.Insert(entry.String()) } if entryInvalidErr { </ins> continue } <del> nodePortLocalSet.activeEntries.Insert(entry.String()) </del> } }

Related discussion:
text: What happened: SCTP nodeport service is not working for all IPs present in the node when ipvs is enabled. It is working only for node's InternalIP. What you expected to happen: SCTP nodeport service must work for all ips present in the node when ipvs is enabled. How to reproduce it (as minimally and precisely as possible): Create a kubernetes cluster with at least one node having multiple interfaces with different IPs. Start an SCTP server deployment. Then create a nodeport service for the same. Now try to reach the service using all the IPs present in that node. The service will be accessible only via node's InternalIP not any other IPs. Environment: Kubernetes version: v1.15.2 OS: ubuntu 18.04 Kernel: 4.15.0-54-generic Network plugin and version (if this is a network-related bug): ipset version v6.34
/sig network /area kube-proxy /area ipvs
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Code change:
Expect(err).NotTo(HaveOccurred(), "error failing a daemon pod") err = wait.PollImmediate(dsRetryPeriod, dsRetryTimeout, checkRunningOnAllNodes(f, ds)) Expect(err).NotTo(HaveOccurred(), "error waiting for daemon pod to revive") <ins> By("Wait for the failed daemon pod to be completely deleted.") err = wait.PollImmediate(dsRetryPeriod, dsRetryTimeout, waitFailedDaemonPodDeleted(c, &pod)) Expect(err).NotTo(HaveOccurred(), "error waiting for the failed daemon pod to be completely deleted") </ins> }) // This test should not be added to conformance. We will consider deprecating OnDelete when the

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: DaemonSet has an e2e test running that has dubious purpose. What you expected to happen: The e2e test should be refactored and commented clearer as it will be part of the conformance.
To elaborate, we're concerned that the following may not actually ensure that DaemonSet recreates Failed Pods: For example, it seems possible that the Node might simply overwrite the Pod status with its own information if it hasn't yet seen the change to the Phase. Ideally, we should verify that the Pod UID we force to Failed no longer shows up in the DaemonSet's list of Pods after the DaemonSet becomes happy again.
Code change:
}, expectErr: false, }, <ins> // IPVS Timeout can be 0 { config: kubeproxyconfig.KubeProxyIPVSConfiguration{ SyncPeriod:    metav1.Duration{Duration: 5 * time.Second}, TCPTimeout:    metav1.Duration{Duration: 0 * time.Second}, TCPFinTimeout: metav1.Duration{Duration: 0 * time.Second}, UDPTimeout:    metav1.Duration{Duration: 0 * time.Second}, }, expectErr: false, }, // IPVS Timeout > 0 { config: kubeproxyconfig.KubeProxyIPVSConfiguration{ SyncPeriod:    metav1.Duration{Duration: 5 * time.Second}, TCPTimeout:    metav1.Duration{Duration: 1 * time.Second}, TCPFinTimeout: metav1.Duration{Duration: 2 * time.Second}, UDPTimeout:    metav1.Duration{Duration: 3 * time.Second}, }, expectErr: false, }, // TCPTimeout Timeout < 0 { config: kubeproxyconfig.KubeProxyIPVSConfiguration{ SyncPeriod: metav1.Duration{Duration: 5 * time.Second}, TCPTimeout: metav1.Duration{Duration: -1 * time.Second}, }, expectErr: true, reason:    "TCPTimeout must be greater than or equal to 0", }, // TCPFinTimeout Timeout < 0 { config: kubeproxyconfig.KubeProxyIPVSConfiguration{ SyncPeriod:    metav1.Duration{Duration: 5 * time.Second}, TCPFinTimeout: metav1.Duration{Duration: -1 * time.Second}, }, expectErr: true, reason:    "TCPFinTimeout must be greater than or equal to 0", }, // UDPTimeout Timeout < 0 { config: kubeproxyconfig.KubeProxyIPVSConfiguration{ SyncPeriod: metav1.Duration{Duration: 5 * time.Second}, UDPTimeout: metav1.Duration{Duration: -1 * time.Second}, }, expectErr: true, reason:    "UDPTimeout must be greater than or equal to 0", }, </ins> } for _, test := range testCases {

Related discussion:
text: <!-- 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: kube-proxy doesn't validate the configurable IPVS tcp, tcpfin and udp timeouts. For example, when kube-proxy starts with , it will always log a warning: . What you expected to happen: kube-proxy should validate --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout flag values at start. How to reproduce it (as minimally and precisely as possible): add flags to kube-proxy Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network /area ipvs
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Code change:
}, }, }, <del> map[string]interface{}{"field": "foo"}, }, true}, </del> <ins> failingObjects: []interface{}{map[string]interface{}{"field": "foo"}}, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { <del> validator, _, err := NewSchemaValidator(&apiextensions.CustomResourceValidation{OpenAPIV3Schema: &tt.args.schema}) </del> <ins> validator, _, err := NewSchemaValidator(&apiextensions.CustomResourceValidation{OpenAPIV3Schema: &tt.schema}) </ins> if err != nil { t.Fatal(err) } <del> if err := ValidateCustomResource(tt.args.object, validator); (err != nil) != tt.wantErr { if err == nil { t.Error("expected error, but didn't get one") } else { t.Errorf("unexpected validation error: %v", err) </del> <ins> for _, obj := range tt.objects { if err := ValidateCustomResource(obj, validator); err != nil { t.Errorf("unexpected validation error for %v: %v", obj, err) } } for _, obj := range tt.failingObjects { if err := ValidateCustomResource(obj, validator); err == nil { t.Errorf("missing error for %v", obj) </ins> } } })

Related discussion:
text: The server-side validation does not check the type of values with . Create a CRD like: Then create a CR: It is not rejected, but should because must not be a boolean.
Code change:
CSI: &v1.CSIPersistentVolumeSource{ Driver:           AzureDiskDriverName, VolumeHandle:     azureSource.DataDiskURI, <del> ReadOnly:         *azureSource.ReadOnly, FSType:           *azureSource.FSType, </del> VolumeAttributes: map[string]string{azureDiskKind: "Managed"}, }, }, AccessModes: []v1.PersistentVolumeAccessMode{v1.ReadWriteOnce}, }, } <ins> if azureSource.ReadOnly != nil { pv.Spec.PersistentVolumeSource.CSI.ReadOnly = *azureSource.ReadOnly } </ins> <del> if *azureSource.CachingMode != "" { </del> <ins> if azureSource.CachingMode != nil && *azureSource.CachingMode != "" { </ins> pv.Spec.PersistentVolumeSource.CSI.VolumeAttributes[azureDiskCachingMode] = string(*azureSource.CachingMode) } <del> if *azureSource.FSType != "" { </del> <ins> if azureSource.FSType != nil { pv.Spec.PersistentVolumeSource.CSI.FSType = *azureSource.FSType </ins> pv.Spec.PersistentVolumeSource.CSI.VolumeAttributes[azureDiskFSType] = *azureSource.FSType } if azureSource.Kind != nil {

Related discussion:
text: What happened: Some of the Azure CSI translation checks in and needs to perform NPE checks for pointer based fields as pointed out in and What you expected to happen: NPE checks should be there How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.15 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:
/assign
/sig storage
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
/priority critical-urgent
Code change:
// Volume is added to asw. Because attach operation fails, volume should not be reported as attached to the node. waitForVolumeAddedToNode(t, generatedVolumeName, nodeName1, asw) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateUncertain, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, false, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, false, asw, volumeAttachedCheckTimeout) </ins> // When volume is added to the node, it is set to mounted by default. Then the status will be updated by checking node status VolumeInUse. // Without this, the delete operation will be delayed due to mounted status

Related discussion:
text: TestRunOneVolumeDetachFailNodeWithReadWriteOnce 4 times since 03-19 23:00 PDT, intermittently ! https://k8s- Still investigating whether this is a tolerable flake or not with more history than testgrid view, or otherwise would appreciate input from anyone with expertise in this test, especially as regards to whether this should be a blocker for tomorrows beta cut. maybe: /sig storage /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
is already open for this, looks like it is attempting to fix it
thank you!!! closing this in favor of that one, which I also to our CI signal project board for visibility. For completeness: since it's a longer standing issue, well identified as a flake and not a failure and also actively in progress, NOT considering it a blocker for the go/nogo signal for the beta tomorrow. /close
Closing this issue. <detailsIn response to : thank you!!! closing this in favor of that one, which I also to our CI signal project board for visibility. For completeness: since it's a longer standing issue, well identified as a flake and not a failure and also actively in progress, NOT considering it a blocker for the go/nogo signal for the beta tomorrow. 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
Code change:
// Volume is added to asw. Because attach operation fails, volume should not be reported as attached to the node. waitForVolumeAddedToNode(t, generatedVolumeName, nodeName1, asw) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateUncertain, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, false, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, false, asw, volumeAttachedCheckTimeout) </ins> // When volume is added to the node, it is set to mounted by default. Then the status will be updated by checking node status VolumeInUse. // Without this, the delete operation will be delayed due to mounted status

Related discussion:
text: pull-kubernetes-unit TestRunOneVolumeDetachFailNodeWithReadWriteOnce Jan 7th, 2022 Check volume <fake-plugin/volume-nameis reported as attached to node <fail-detach-node, got false, expected true No response_ /sig storage
/cc
this is the top unit test flake according to
cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
I think this test is no longer flaky by checking the test grid, close it now.
Unfortunately this does still seem to be flaky: Here was the output from : /reopen
Reopened this issue. <detailsIn response to : Unfortunately this does still seem to be flaky: 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
/remove-lifecycle stale
still the case
How about adding some logging to help troubleshoot this? I looked at it a little, but it is hard to tell which part of the test is failing. PR
/
This is still happening
/triage accepted
From the logs, in the OneVolumeDetachFailNodeWithReadWriteOnce test, succeeded, but the next verification failed. In verifyVolumeAttachedToNode, the attachState is from calling and within asw, it calls . In verifyVolumeReportedAsAttachedToNode, the volumes are obtained from calling , it seems that the node is not in asw.nodesToUpdateStatusFor at this step. Cannot reproduce locally. I tried to run the test 100 times locally with debug.Stack()... 3 * 100 times all passed.
Tried to run stress test on my linux machine as well but still cannot reproduce. Command: Result: Also tried running n process in parallel. Command: Result:
It seems like it happens more frequently.
Code change:
// Volume is added to asw. Because attach operation fails, volume should not be reported as attached to the node. waitForVolumeAddedToNode(t, generatedVolumeName, nodeName1, asw) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateUncertain, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, false, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, false, asw, volumeAttachedCheckTimeout) </ins> // When volume is added to the node, it is set to mounted by default. Then the status will be updated by checking node status VolumeInUse. // Without this, the delete operation will be delayed due to mounted status

Related discussion:
text: But I may have no time to dig into the cause. Let's see.
cc as the test author.
The problem is that this test has a lot of dependency on the sleeps that are hardcoded with a very narrow scope, but our CI seems to be able to stress it much more. As soon as you slightly change one of the sleep duration it starts to flake locally The test can not make an assumption that timing is perfect, even more in the sub second range can someone in sig-storage review this test and make it less dependant on those tight sleeps?
According to most failures, it failed at Line 660. Let me run some stress locally. with 250ms sleep with 100ms sleep
I agree this test case is too brittle due to its specific timing dependencies. To fix this, I suggest reworking the test case to: 1) Add retry with timeout to wait for final conditions 2) Remove the intermediate timing-based state transition checks. Instead, we can keep track of state transitions in the Fakes and validate those stats. wdyt?
Friendly ping from 1.27 CI Signal that this test is still a noisy flake on the master-blocking dashboard as CI Signal has flagged it in and