jiebi/CodeConvo huggingface dataset:
Change:
// 30 seconds by default. // Based on the above check if the pod receives the traffic. ginkgo.By("checking client pod connected to the backend 1 on Node IP " + serverNodeInfo.nodeIP) <del> if err := wait.PollImmediate(5*time.Second, time.Minute, logContainsFn(podBackend1)); err != nil { </del> <ins> if err := wait.PollImmediate(5*time.Second, time.Minute, logContainsFn(podBackend1, podClient)); err != nil { </ins> logs, err = e2epod.GetPodLogs(cs, ns, podClient, podClient) framework.ExpectNoError(err) framework.Logf("Pod client logs: %s", logs)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: n/a Which test(s) are failing: "should resolve connection reset issue [Slow]" Since when has it been failing: it never worked Testgrid link: n/a Reason for failure: The image used for the test is using only IPv4 Anything else we need to know: We should: [x] refactor the code to support IPv6 [ ] ~consolidate the image in agnhost~ [x] configure an IPv6 job to test network https://k8s-,%20IPv6,%20master
/assign /sig-network
GitHub didn't allow me to assign the following users: Billy99. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /sig-network 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
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
/help wanted
/help wanted /good-first-issue
/remove-good-first-issue the agnhost promotion process is not something easy for new contributors
Hi, I would like to contribute to this.
good, thanks
sorry , I needed to fix it and I took over, thanks for stepping up /assign /remove help-wanted
OK.Yesterday I have refactor the code to support IPv6, but I understand wrong about consolidate the image in agnhost. I'm sorry for not being able to help.
no worries, it was trickier than I thought, thanks again for your help
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
limits = quota.Max(limits, pod.Spec.InitContainers[i].Resources.Limits) } <ins> if feature.DefaultFeatureGate.Enabled(features.PodOverhead) { requests = quota.Add(requests, pod.Spec.Overhead) limits = quota.Add(limits, pod.Spec.Overhead) } </ins> result = quota.Add(result, podComputeUsageHelper(requests, limits)) return result, nil }

Discussion:
assume that: cluster with only one node with 4G allocatable memory Define test runtimeclass with PodOverhead Define resourceQuota test under test namespace with 4Gi memory limit Create Pod with test runtimeClass under test namespace podOverhead resource not counted into resourceQuota used info podOverhead resource counted into node requests info try to create one more pod with 2G memory requests, resourceQuota check passed but failed to schedule because it requests 2G+200M memory podOverhead resource should be counted into resourceQuota used info to keep resourceQuota check and schedule check be consistent. Kubernetes version 1.16
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
/assign
/sig node
ref:
-- can you verify that you have the feature gate enabled for pod overhead for api-server, as well as kubelet and scheduler? Example:
I made a cluster with the following command, using crio as a container runtime( is not available with Docker) And the issue was reproduced.
overhead feature enabled, the overhead resource has been counted into requests during scheduling but not counted into resourcequota
Currently, PodOverhead is defined as a fixed resource. this value looks like the average usage value and being into requests resource during scheduling. type Overhead struct { PodFixed *ResourceList } My use case is kata_container, the VMM related processes consume much overhead resource when pod running with high workload. A small overhead(small cgroup limits) will trigger oom but a big value result that big overhead requests take into account during scheduling. So how about define PodOverhead including limits and requests like that in Pod resources definition. It could be helpful resources: limits: memory: 1Gi requests: memory: 200M
CC: FYI
Change:
tokenJsonBlob, err := credentialprovider.ReadUrl(metadataToken, g.Client, metadataHeader) if err != nil { <ins> glog.Errorf("while reading access token endpoint: %v", err) </ins> return cfg } email, err := credentialprovider.ReadUrl(metadataEmail, g.Client, metadataHeader) if err != nil { <ins> glog.Errorf("while reading email endpoint: %v", err) </ins> return cfg }

Discussion:
It looks like we always try and hit the metadata server even if we aren't on GCE. We then print an error out. This should either be silent (assume after X attempts that we aren't on GCE?) or should only be activated with an option. Email thread: !topic/google-containers/w-ei5Xs6K0Y
cc:
FYI, the way the credentialprovider logic is set up, providers are asked once per keyring creation whether they are enabled. If they are enabled, then they are asked to provide their contribution to .dockercfg each time the lazy keyring is accessed. For efficiency, there is a caching provider, which composes with heavier providers and stores their .dockercfg contribution for a predetermined TTL. What was happening here was that "Enabled()" for our GCE-metadata implementations was logging about errors fetching "http://metadata", where the entire "Enabled()" check is "err == nil".
I believe that this was fixed by
Change:
package windows import ( <del> "fmt" "io" "net/http" "os" </del> <ins> "time" appsv1 "k8s.io/api/apps/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/kubernetes/pkg/controller/deployment/util" "k8s.io/kubernetes/test/e2e/framework" </ins> ) <del> // downloadFile saves a remote URL to a local temp file, and returns its path. // It's the caller's responsibility to clean up the temp file when done. func downloadFile(url string) (string, error) { response, err := http.Get(url) if err != nil { return "", fmt.Errorf("unable to download from %q: %w", url, err) } defer response.Body.Close() tempFile, err := os.CreateTemp("", "") if err != nil { return "", fmt.Errorf("unable to create temp file: %w", err) } defer tempFile.Close() _, err = io.Copy(tempFile, response.Body) return tempFile.Name(), err </del> <ins> // waits for a deployment to be created and the desired replicas // are updated and available, and no old pods are running. func waitForDeployment(getDeploymentFunc func() (*appsv1.Deployment, error), interval, timeout time.Duration) error { return wait.PollImmediate(interval, timeout, func() (bool, error) { deployment, err := getDeploymentFunc() if err != nil { if apierrors.IsNotFound(err) { framework.Logf("deployment not found, continue waiting: %s", err) return false, nil } framework.Logf("error while deploying, error %s", err) return false, err } framework.Logf("deployment status %s", &deployment.Status) return util.DeploymentComplete(deployment, &deployment.Status), nil }) </ins> }

Discussion:
Cluster api provides a framework to run the e2e tests which uses the conformance image: The gmsa tests use bash to install the webhook: The test will fail when run in the conformance image because of the bash: we should install the component another way run this e2e conformance image with /sig windows fyi <details</details<details</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
Conformance image:
Hi does the "work e2e" test case pass? Deploying GMSA webhook is the same for both "work e2e" and this test case.
no, they both fail due to bash not being present in the conformance image. The gmsa tests themselves pass if I run locally
/sig testing
Change:
OffendingContainersUsageKey = "offending_containers_usage" // StarvedResourceKey is the key for the starved resource in eviction event annotations StarvedResourceKey = "starved_resource" <ins> // thresholdMetMessageFmt is the message for evictions due to resource pressure. thresholdMetMessageFmt = "Threshold quantity: %v, available: %v. " </ins> ) var (

Discussion:
when the pod is evicted due to low imagefs.available, the prompt is difficult to understand. it showed: But the container was evicted not by exceeding its request of 0 ephemeral-storage, but due to reaching the evictionHard of the node. The correct prompt message points out the reason for the pod eviction. don't print "which exceeds its request of 0.", because the container was evicted not by exceeding its request of 0. % oc label mcp worker custom-kubelet-eviction=small-pods evictionHard by creating a kubeletconfig % oc create -f custom-kubelet- custom-kubelet- several minutes, the mcp worker finish rolling out to the latest mc a pod % oc create -f hello-pod- hello-pod- a large file in container, make imagefs.available < 90Gi (the current available disk size is 111G ) command terminated with exit code 137 the node status the pod status % oc get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-pod-2 0/1 ContainerStatusUnknown 1 7m58s 10.131.0.7 ip-10-0-213- <none<none% oc get pod hello-pod-2 -o yaml No response <details</details<detailsaws </details<details</details<details</details<details</details<details</details
/sig node
/assign
/assign
/triage accepted
Change:
options := []string{} if readOnly { options = append(options, "ro") <ins> } else { // as per https://cloud.google.com/compute/docs/disks/add-persistent-disk#formatting options = append(options, "discard") </ins> } if notMnt { diskMounter := &mount.SafeFormatAndMount{Interface: mounter, Runner: exec.New()}

Discussion:
GCE PD docs so unused blocks can be freed back into the cloud and performance gains realized. Rummaging through the source of the GCE PD and mounter stuff in Kube, it does not appear that that's being done (the old shell script version of safeformatand_mount does, but I don't think that's used). I haven't confirmed that it's the case at runtime for sure, though, although I will be able to shortly.
I LGTMed the PR and then realized it needed more work. Reverting it and assigning it to ciwang. We need to make sure that we only use the "discard" mount option when the fs supports it. Assigning to ciwang for now. If anyone else wants to work on it feel free to grab it.
Assigning to This fell through the cracks as ciwang was working in other areas. This did not make 1.4 either moving to next-candidate.
Issues go stale after 30d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. 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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
if err != nil { return result, err } <del> trace.Step("Prioritizing done") </del> metrics.SchedulingAlgorithmPriorityEvaluationDuration.Observe(metrics.SinceInSeconds(startPriorityEvalTime)) metrics.DeprecatedSchedulingAlgorithmPriorityEvaluationDuration.Observe(metrics.SinceInMicroseconds(startPriorityEvalTime)) metrics.SchedulingLatency.WithLabelValues(metrics.PriorityEvaluation).Observe(metrics.SinceInSeconds(startPriorityEvalTime)) metrics.DeprecatedSchedulingLatency.WithLabelValues(metrics.PriorityEvaluation).Observe(metrics.SinceInSeconds(startPriorityEvalTime)) host, err := g.selectHost(priorityList) <del> trace.Step("Selecting host done") </del> <ins> trace.Step("Prioritizing done") </ins> return ScheduleResult{ SuggestedHost:  host, EvaluatedNodes: len(filteredNodes) + len(failedPredicateMap) + len(filteredNodesStatuses),

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We have enabled in genericscheduler. However, the steps being traced seem outdated. In particular, the "snapshot" is expensive and should be traced. Other steps can be traced as well wherever appropriate, e.g., PreFilter. Why is this needed: Improve granularity of tracing. /sig scheduling
/assign
Change:
}) } } <ins> func Test_RaceTerminateRSList(t *testing.T) { ipvs := &utilipvstest.FakeIPVS{} gracefulTerminationManager := NewGracefulTerminationManager(ipvs) go func() { for i := 1; i <= 10; i++ { for j := 1; i <= 100; j++ { gracefulTerminationManager.rsList.add(makeListItem(i, j)) } } }() if !gracefulTerminationManager.rsList.flushList(gracefulTerminationManager.deleteRsFunc) { t.Error("failed to flush entries") } } func makeListItem(i, j int) *listItem { vs := fmt.Sprintf("%d.%d.%d.%d", 1, 1, i, i) rs := fmt.Sprintf("%d.%d.%d.%d", 1, 1, i, j) return &listItem{ VirtualServer: &utilipvs.VirtualServer{ Address:  netutils.ParseIPSloppy(vs), Protocol: "tcp", Port:     uint16(80), }, RealServer: &utilipvs.RealServer{ Address: netutils.ParseIPSloppy(rs), Port:    uint16(80), }, } } </ins>

Discussion:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)
Change:
import ( "fmt" "reflect" <ins> "strconv" </ins> "testing" "github.com/google/gofuzz"

Discussion:
In Go you cannot take the address of a because the map implementation hides that from you. Our conversion library assumes that any reflected map value can have Addr() taken, which causes a panic when you try to do the following for PodInfo conversion: The conversion code tries to call Addr() on the reflect.Value (the map's value, ContainerStatus value object) which fails because it cannot have an address. I worked around it by registering a conversion function on *PodInfo and then manually converting the map.
Oh you mean the reflection code can't addr that? ok sounds like a bug. Non-reflection code can certainly do it:
That playground is taking the address of a value before it's in the struct. You can't take the address of m ----- Original Message -----
Right, because go does magical c++ style references there. But I thought the map copying code handled that case specially already?
I think I see what you're talking about. I'll make a test.
I repro'd. Will fix.
It was actually the source value that caused the trouble. Thanks for the report!
Sorry, should have been clearer. ----- Original Message -----
Note that this map violates our API conventions. It should be a list of named subobjects.
Yeah this field has always been problematic. It's still a bug regardless-- could have triggered copying other maps.
Change:
dswp.actualStateOfWorld.MarkRemountRequired(uniquePodName) // Remove any stored errors for the pod, everything went well in this processPodVolumes dswp.desiredStateOfWorld.PopPodErrors(uniquePodName) <ins> } else if dswp.podHasBeenSeenOnce(uniquePodName) { // For the Pod which has been processed at least once, even though some volumes // may not have been reprocessed successfully this round, we still mark it as processed to avoid // processing it at a very high frequency. The pod will be reprocessed when volume manager calls // ReprocessPod() which is triggered by SyncPod. dswp.markPodProcessed(uniquePodName) </ins> } }

Discussion:
It happens during the "delete" phase in the load test. ! In perf-dash we can see that in total there are ~20M requests like that during the load test. ! It started in Sep 2019 (sic!), so probably when we enabled PVs in our load tests. We haven't detected it so far as, strangely, it doesn't seem to be impacting our scalability SLIs. We should investigate this. /sig scalability
I checked and we create 35 PersistentVolumeClaims per 100 nodes. So in case of 5K node test there will be 1750 PVCs in the cluster. This is close to the 2K of GET PVC requests we see.
Let's analyze the last run of 5K node test in more depths - Grafana: ! As I wrote already somewhere here, it happens during the delete phase. We reach the peak of ~2K QPS around 2:30 AM UTC in that run. Let's check the logs (api-server, kubelets) around that time.
Looking at the api-server logs one can easily tell that something is wrong. It's swamped by GET persistentvolumeclaim requests:
Restricting the logs to a single stateful set on a single node (single client ip) - it also doesn't look right. Total such requests from this IP address: So it looks like a single kubelet issued almost 20K GET requests for this PVC within ~75min, which gives us ~4 QPS from a single kubelet...
From the scheduler logs it looks like the statefulset pod for this PVC was bound on the node Let's check the kubelet logs there
Kubelet logs: Bingo, around the time when the issue happens, it's full of the following logs:
Looks like the errors disappeared exactly when the pod was deleted So, what happens here is partially caused by our test as it may happen that we'll first delete PVC and won't delete the corresponding pod for the next O(1h). Nevertheless, the code in the should be fixed so it doesn't cause kubelet to send ~4QPS of GET PVC requests in such case.
/sig node /sig storage
There is a pending discussion about ways to fix it in
Thanks for fixing that! I know how much work was it and I really appreciate!
Change:
"k8s.io/kubernetes/pkg/api/legacyscheme", "k8s.io/kubernetes/pkg/api/service", "k8s.io/kubernetes/pkg/api/v1/pod", <ins> "k8s.io/kubernetes/pkg/api/v1/resource", "k8s.io/kubernetes/pkg/api/v1/service", </ins> "k8s.io/kubernetes/pkg/apis/apps", "k8s.io/kubernetes/pkg/apis/apps/validation", "k8s.io/kubernetes/pkg/apis/autoscaling",

Discussion:
What happened: There is to manage import ways under but that doesn't work at our upstream CI. We can enable it by But if doing that, we will face the following error with What you expected to happen: I hope the check is always running to block invalid import ways at upstream CI system. How to reproduce it (as minimally and precisely as possible): As line into arguments.InputDirs of
/sig testing /area e2e-test-framework
Change:
package fake import ( <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/runtime"

Discussion:
Opening this issue based on what I ran into on with namespace as follows While unit testing the controller, we create a fake client and setup the controller to run using the client. This ends up creating a having the namespace set to When the call eventually reaches The action gets associated with a namespace only if the object has a namespace associated with it. Which in this will be Which will result in the error in to manage the event like does. In case if the namespace is set to Above is a test case that can easily simulate the issue in question. Referring back to the test under PR NA <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /triage accepted 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
Change:
for i := range volumes { vol := &volumes[i] // so we can set default values el := errs.ErrorList{} <del> // TODO(thockin) enforce that a source is set once we deprecate the implied form. if vol.Source != nil { el = validateSource(vol.Source).Prefix("source") </del> <ins> if vol.Source == nil { // TODO: Enforce that a source is set once we deprecate the implied form. vol.Source = &api.VolumeSource{ EmptyDir: &api.EmptyDir{}, } </ins> } <ins> el = validateSource(vol.Source).Prefix("source") </ins> if len(vol.Name) == 0 { el = append(el, errs.NewFieldRequired("name", vol.Name)) } else if !util.IsDNSLabel(vol.Name) {

Discussion:
Given the following configuration: No volume will be mounted inside the resulting container: If I modify the volumes element to look like this: I get a volume mounted on /srv: I see the same behavior using either or .
I suspect I broke this default behavior. Hopefully someone else can provide a fix? I'll fix if it's still pending in a day or two. (In the middle of other things)
I will look into this.