jiebi/CodeConvo huggingface dataset:
Change:
e2epod.WaitForPodsRunningReady(ctx, f.ClientSet, f.Namespace.Name, 1, 0, timeout) ginkgo.By("Getting container stats for pod") <del> nodeStats, err := e2ekubelet.GetStatsSummary(ctx, f.ClientSet, targetNode.Name) framework.ExpectNoError(err, "Error getting node stats") </del> statsChecked := false <del> for _, podStats := range nodeStats.Pods { if podStats.PodRef.Namespace != f.Namespace.Name { continue } // check various pod stats if *podStats.CPU.UsageCoreNanoSeconds <= 0 { framework.Failf("Pod %s/%s stats report cpu usage equal to %v but should be greater than 0", podStats.PodRef.Namespace, podStats.PodRef.Name, *podStats.CPU.UsageCoreNanoSeconds) } if *podStats.Memory.WorkingSetBytes <= 0 { framework.Failf("Pod %s/%s stats report memory usage equal to %v but should be greater than 0", podStats.PodRef.Namespace, podStats.PodRef.Name, *podStats.CPU.UsageCoreNanoSeconds) } for _, containerStats := range podStats.Containers { statsChecked = true // check various container stats if *containerStats.CPU.UsageCoreNanoSeconds <= 0 { framework.Failf("Container %s stats report cpu usage equal to %v but should be greater than 0", containerStats.Name, *containerStats.CPU.UsageCoreNanoSeconds) } if *containerStats.Memory.WorkingSetBytes <= 0 { framework.Failf("Container %s stats report memory usage equal to %v but should be greater than 0", containerStats.Name, *containerStats.Memory.WorkingSetBytes) } if *containerStats.Logs.UsedBytes <= 0 { framework.Failf("Container %s stats log usage equal to %v but should be greater than 0", containerStats.Name, *containerStats.Logs.UsedBytes) } } } </del> <ins> wait.Poll(2*time.Second, timeout, func() (bool, error) { return ensurePodsStatsOnNode(ctx, f.ClientSet, f.Namespace.Name, targetNode.Name, &statsChecked) }) </ins> if !statsChecked { framework.Failf("Failed to get stats for pod %s/%s", f.Namespace.Name, podName)

Discussion:
ci-kubernetes-e2e-capz-master-containerd-windows Kubernetes e2e suite: [It] [sig-windows] [Feature:WindowsHostProcessContainers] [MinimumKubeletVersion:1.22] HostProcess containers container stats validation feb 8th 2023 reading of the log is showing reporting zero It looks like the pod had started up just as it check the failure on the test. Adding a retry or a longer wait might make the test more reliable /sig windows
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
Change:
nodeInfo: schedulercache.NewNodeInfo( newResourcePod(schedulercache.Resource{MilliCPU: 10, Memory: 10, StorageOverlay: 20})), fits: false, <del> test: "due to init container scratch disk", </del> <ins> test: "due to container scratch disk", </ins> reasons: []algorithm.PredicateFailureReason{ NewInsufficientResourceError(v1.ResourceCPU, 1, 10, 10), NewInsufficientResourceError(v1.ResourceStorageScratch, 1, 20, 20),

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No Note: Please file issues for subcomponents under the appropriate repo What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): local isolation Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Bug Kubernetes version (use ): kubernetes HEAD Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: For local storage isolation, overlay resource predicates for pod with only overlay or scratch storage request doesn't work. What you expected to happen: If a pod requests only overlay or scratch storage, then local storage isolation feature should limit the pods. How to reproduce it (as minimally and precisely as possible): Run local cluster from master branch, and create following pods (against a machine with less overlay fs than 1024Gi). Anything else we need to know:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig storage
CC
Fix is ready:
Change:
framework.ExpectNoError(err, fmt.Sprintf("error while waiting for service:%s err: %v", serviceName, err)) hostExec := utils.NewHostExec(f) defer hostExec.Cleanup() <del> node, err := e2enode.GetRandomReadySchedulableNode(cs) framework.ExpectNoError(err) </del> <ins> node := &nodes.Items[0] </ins> cmd := "iptables-save" if framework.TestContext.ClusterIsIPv6() { cmd = "ip6tables-save"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- - At least 08/08 sequentially performs operations that take ~20s on average. Example: For a 5000 nodes test this causes a major timeout. excludes tests with tag which SCTP had until was merged. This is why there is a shift in red cells in the testgrid after 08/15. We will add a pattern excluding until this issue is resolved. /assign /cc
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 network
/assign
Change:
// Apply implements Manager. func (f *managedFieldsUpdater) Apply(liveObj, appliedObj runtime.Object, managed Managed, fieldManager string, force bool) (runtime.Object, Managed, error) { <del> formerManaged := managed.Fields().Copy() </del> object, managed, err := f.fieldManager.Apply(liveObj, appliedObj, managed, fieldManager, force) if err != nil { return object, managed, err } <del> if object != nil || !managed.Fields().Equals(formerManaged) { </del> <ins> if object != nil { </ins> managed.Times()[fieldManager] = &metav1.Time{Time: time.Now().UTC()} <del> } if object == nil { </del> <ins> } else { </ins> object = liveObj.DeepCopyObject() internal.RemoveObjectManagedFields(object) }

Discussion:
I created an object with , and later I updated the same object with another . After that I looked at the object's managedFields, and saw nothing about the update. Here is what I got after the second apply: I expected managedFields to get updated by the second . No response <details</details<detailsnone </details<details</details<detailskubeadm </details<detailsdocker </details<details</details
/cc
I also saw the timestamp not updated when I updated using client-go and typed client stubs, Apply method, patch type .
/assign /triage accepted
/cc
The is not updated because you are not changing the structure of the object (adding or removing fields). According to , the time is updated if and only if the fieldSet is changed. It does not take into account the value of fields. One option would be to not compare the fieldSets but directly compare the liveObject & newObject for differences and update the field accordingly. Is it the desired behavior to update the time of when only the value is updated?
Yes! Look at the first paragraph of .
is that documentation correct? Is this what we intended?
I don't see any mention to the timestamp in that first paragraph. We've clarified recently the exact semantic of the timestamp, as defined here: I think you've identified the wrong code if you want to go ahead and fix it, go ahead, I'll happily review!
Change:
} var username string <del> if err := c.unmarshalClaim(a.jwtAuthenticator.ClaimMappings.Username.Claim, &username); err != nil { return nil, false, fmt.Errorf("oidc: parse username claims %q: %v", a.jwtAuthenticator.ClaimMappings.Username.Claim, err) </del> <ins> usernameClaim := a.jwtAuthenticator.ClaimMappings.Username.Claim if err := c.unmarshalClaim(usernameClaim, &username); err != nil { return nil, false, fmt.Errorf("oidc: parse username claims %q: %v", usernameClaim, err) </ins> } <del> if a.jwtAuthenticator.ClaimMappings.Username.Claim == "email" { </del> <ins> if usernameClaim == "email" { </ins> // If the email_verified claim is present, ensure the email is valid. // https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims if hasEmailVerified := c.hasClaim("email_verified"); hasEmailVerified {

Discussion:
Follow up PR: would be good to use some local vars to make these statements shorter. Originally posted by in
/sig auth /triage accepted /kind cleanup /assign
Change:
} } <del> if *serverVersion { </del> <ins> if *serverVersion != verflag.VersionFalse { </ins> got, err := kubeClient.ServerVersion() if err != nil { fmt.Printf("Couldn't read version from server: %vn", err) os.Exit(1) } <del> fmt.Printf("Server Version: %#vn", got) os.Exit(0) </del> <ins> if *serverVersion == verflag.VersionRaw { fmt.Printf("%#vn", *got) os.Exit(0) } else { fmt.Printf("Server: Kubernetes %sn", got) os.Exit(0) } </ins> } if *preventSkew {

Discussion:
It's hard to tell if they match right now.
who has been changing this stuff. :)
Ah yes... I was thinking of adding a flag to print the %r of the version.Info... Do you think that would be an appropriate flag name? I'll start working on the PR since it's probably time to refactor the code to take the other bits from git I have been pushing through ldflags...
I'd change the current behavior rather than add a new flag. I don't really care which way it ends up looking as long as both flags print the same format :)
Fixed by
Change:
exit 1 fi <ins> # Travis continuous build uses a head go release that doesn't report # a version number, so we skip this check on Travis.  Its unnecessary # there anyway. if [ ${TRAVIS} != "true" ]; then GO_VERSION=($(go version)) if [ ${GO_VERSION[2]} < "go1.2" ]; then echo "Detected go version: ${GO_VERSION}." echo "Kubernetes requires go version 1.2 or greater." echo "Please install Go version 1.2 or later" exit 1 fi fi </ins> pushd $(dirname "${BASH_SOURCE}")/.. >/dev/null KUBE_REPO_ROOT="${PWD}" KUBE_TARGET="${KUBE_REPO_ROOT}/output/go"

Discussion:
Which jobs are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /milestone v1.18 /priority critical-urgent /cc /sig cluster-lifecycle /area provider/gcp
/reopen Reopening, to observe the job.
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Several of the recent failures appear to be this: cc
next run should pick up the change in we have had boskos outage clearing up now.
This is still not going to work because k/k has removed the .deb files we've been downloading from the CI artifacts:
FYI we are discussing in Slack how to proceed to resolve this. I doubt it will be a simple, quick fix, though.
me and did mention this on the k-dev: !msg/kubernetes-sig-cluster-lifecycle/q934Ah3SD64/JukDA9wsAgAJ given there were no replies we assumed there are no users. but this is definitely for the better as we removed the Bazel build of packages from k/k. 's PR seems to use binaries directly: i will have a look.
Closed via There is a possibility we will publish debs again in the future (via ), but while that tool is in flux, I don't want anyone depending on it. Thanks for the fix, /close
Closing this issue. <detailsIn response to : Closed via /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

fails with this trace: Please help.
Thanks for trying Kubernetes, sorry it didn't work for you. Do you have an old version of go installed? We currently are building with go 1.2, you can run to find the version. I tried to repro. this on a clean client, and I can't seem to reproduce the problem, also our Travis build is green: https://travis-, so I think that the problem must be somewhere in your set up. Please let me know some more details and we can help you debug. Best! --brendan
I validated that this is due to trying to compile with Go version 1.0 rather than 1.2. I'll update the scripts to validate that the appropriate version of Go is installed. So please upgrade your installed version of golang, and try again. Thanks! --brendan
Change:
// TODO: Use the addToNetwork function to obtain the IP of the Pod. That will assume idempotent ADD call to the plugin. // Also fix the runtime's call to Status function to be done only in the case that the IP is lost, no need to do periodic calls func (plugin *kubenetNetworkPlugin) Status(namespace string, name string, id kubecontainer.ContainerID) (*network.PodNetworkStatus, error) { <ins> plugin.mu.Lock() defer plugin.mu.Unlock() </ins> cidr, ok := plugin.podCIDRs[id] if !ok { return nil, fmt.Errorf("No IP address found for pod %v", id)

Discussion:
I gathered e2e test results of suite for last 100 runs. The following is the list of flaky tests. Some might not be related to . I will start with the service tests. Any help would be appreciated. Detail list: Jenkins project:
cc/ Cluster team is working on to make kubenet default. Once we switch this to production, we don't need to restart docker to configure cbr0.
After a bunch of PRs got merged, the kubenet suite is much more stable. One more known flake can be fixed by I will post new flake tests here.
Just bump into a new failure: One of the nodes () got panic: Looks like it crashed at shaper reset.: Can you take a look?
Change:
var ( gpuResourceName v1.ResourceName <del> dsYamlURL       string </del> ) func makeCudaAdditionDevicePluginTestPod() *v1.Pod {

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /cc /priority critical-urgent /milestone v1.19
Appears to have started failing after , which seems unrelated. /cc
according to the build log , the test timed out because it could not find gpu on any nodes. Is it probably a test-infra issue?
I think you are right, I don't see anything changing in the config so must be underlying infra issue /cc
yes, the issue is that the nodes do not have the GPU required to run the test The same infra commit () was used for the last passing job () and the first failing job ()
not sure who owns the node setup for the gpu tests, but I would guess
test-infra-maintainers owns e.g. prow, I don't think anything there relates to the GPUs the infra commit (test-infra commit) not changing suggests perhaps a change to the scripts / test harness in this repo?
the delta between the passing and failing runs only changed an ingress e2e test ()
The image is used in when installing the Nvidia driver. Given that ([1]) is lastly updated on July 17, 2020 at 12:22:11 AM UTC-7 (latest tag points to v2.0.0), does it seem this version is incompatible? BTW: the latest successful run pulled the image with SHA: 8d86a652759f80595cafed7d3dcde3dc53f57f9bc1e33b27bc3cfa7afea8d483 ([2]), maybe we can try that SHA specifically? [1]: [2]:
Forgot to mention, the shows that the deamonset was pending:
yes, and the log also shows that the pod was pending because the init container failed to complete could we change the image to  whose digest is exactly .
Change:
RollbackTemplateUnchanged = "DeploymentRollbackTemplateUnchanged" // RollbackDone is the done rollback event reason RollbackDone = "DeploymentRollback" <del> // OverlapAnnotation marks deployments with overlapping selector with other deployments // TODO: Delete this annotation when we no longer need to support a client //       talking to a server older than v1.6. OverlapAnnotation = "deployment.kubernetes.io/error-selector-overlapping-with" </del> // Reasons for deployment conditions // // Progressing:

Discussion:
The Deployment overlap annotation () is no longer populated nor used by 1.6+ on the server side. However, in we maintained knowledge of the annotation for 1.6 clients in case they talk to pre-1.6 servers. That PR also adds code to clean up the annotation whenever it's found in 1.6+ clusters, so that pre-1.6 clients don't see it and make the wrong assumptions. The code handling this annotation should be removed when all the following conditions are met: We no longer support a 1.5.x client talking to the latest server version. We no longer support upgrading the server directly from 1.5.x to the latest version. The soonest milestone that meets both conditions according to the is v1.8. This issue should be moved to that milestone once it exists.
TODOs: [x] deployment controller: [x] deployment util: [x] deployment reaper: [x] deployment describer:
I can help on this
/assign
GitHub didn't allow me to assign the following users: wanghaoran1988. Note that only can be assigned. <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
thanks, feel free to send patches
Change:
// IsNotFound returns true if the specified error was created by NewNotFound. // It supports wrapped errors. func IsNotFound(err error) bool { <del> return ReasonForError(err) == metav1.StatusReasonNotFound </del> <ins> reason, code := reasonAndCodeForError(err) if reason == metav1.StatusReasonNotFound { return true } if _, ok := knownReasons[reason]; !ok && code == http.StatusNotFound { return true } return false </ins> } // IsAlreadyExists determines if the err is an error which indicates that a specified resource already exists.

Discussion:
Checked a method error using when the error was caused by a validating webhook that returns a 403 response. In this particular case, the error was generated from a validating webhook implemented with controller-runtime that returns controller-runtime's response. to return true. returned false Many (but not all) of the other family of functions in suffer the same kind of problem. I have changes ready to submit in a PR if we can get agreement that this is a problem and that it should be fixed in the functions that ought to check the of an erorr value that is or wraps an Kubernetes version (use ): 19.3 for the server
/sig api-machinery
are you going to send a PR for this? The issue description looks reasonable. /triage accepted
Thanks, PR is submitted.
/assign
Change:
fi params+=" --tls-cert-file=/etc/srv/kubernetes/server.cert" params+=" --tls-private-key-file=/etc/srv/kubernetes/server.key" <ins> params+=" --requestheader-client-ca-file=/etc/srv/kubernetes/aggr_ca.crt" params+=" --requestheader-allowed-names=aggregator" params+=" --requestheader-extra-headers-prefix=X-Remote-Extra-" params+=" --requestheader-group-headers=X-Remote-Group" params+=" --requestheader-username-headers=X-Remote-User" params+=" --proxy-client-cert-file=/etc/srv/kubernetes/proxy_client.crt" params+=" --proxy-client-key-file=/etc/srv/kubernetes/proxy_client.key" params+=" --enable-aggregator-routing=true" </ins> params+=" --client-ca-file=/etc/srv/kubernetes/ca.crt" params+=" --token-auth-file=/etc/srv/kubernetes/known_tokens.csv" params+=" --secure-port=443"

Discussion:
We want kubemark setups to be as similar to real clusters as possible. Since we are launching kube-aggregator in real clusters, we should add a possibility (and probably also enable by default) to have kube-aggregator in front of apiserver(s).
was working on being able to use it in e2es.
With kube-aggregator integrated into kube-apiserver, is this still relevant?
There are a few flags which need to be set up for kubemark to actually be properly testing with the aggregator. I am digging around in that code this week anyway. I will try to get to it and make sure its set up properly.
Thanks for looking. Let me know if I you need something.
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 3 days, the issue will be moved out of the v1.8 milestone. kind: Must specify at most one of ['kind/bug', 'kind/feature', 'kind/cleanup']. priority: Must specify at most one of ['priority/critical-urgent', 'priority/important-soon', 'priority/important-longterm']. <detailsAdditional instructions available <a href=""here</a</details
Change:
apiserver_dropped_requests_total{request_kind="mutating"} 1 # HELP apiserver_request_total [STABLE] Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code. # TYPE apiserver_request_total counter <del> apiserver_request_total{code="429",component="apiserver",dry_run="",group="",resource="pods",scope="cluster",subresource="",verb="POST",version="v1"} 1 </del> <ins> apiserver_request_total{code="429",component="apiserver",dry_run="",group="",resource="pods",scope="resource",subresource="",verb="POST",version="v1"} 1 </ins> `, }, {

Discussion:
I've observed, that some metrics has and labels. (create) requests are "single resource", therefor they should be classified as . Def: customresourcehandler uses , which is based on the RequstInfo only: the RequestInfo is based only on the requests: method and url example: e.g: Since this RequestInfo has Name and Namespace empty, it is classified as . In a similar way it could be explained why: There's a mismatch in scope classification between built-in and custom resources: The key difference - the check if either "name" was provided OR it is a : Where the metrics.CleanScope ONLY checks, if name is not-empty. Tested: = v1.20 There were other scope related issues <1.20 and the distinction is not obvious. <details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted