jiebi/CodeConvo huggingface dataset:
Change:
defer createWait.Done() var err error <del> podTemplate := &template </del> <ins> podTemplate := template.DeepCopy() </ins> if utilfeature.DefaultFeatureGate.Enabled(features.ScheduleDaemonSetPods) { <del> podTemplate = template.DeepCopy() </del> // The pod's NodeAffinity will be updated to make sure the Pod is bound // to the target node by default scheduler. It is safe to do so because there // should be no conflicting node affinity with the target node.

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?: What happened: Create a DaemonSet. It'll create pods with schedulerName=default-scheduler. However, the DaemonSet pods aren't actually scheduled by default-scheduler but DaemonSet controller.
If the "schedulerName" is empty, apiserver will set the default value to "default-scheduler". To avoid the confusion, I think we can let DaemonSet set this field (for example 'ds-controller') when creating the DaemonSet pods, WDYT?
What's "schdulerName" for? Is it just for telling the users who scheduled this pod, or is this information used by other resources in the system? Also, I'd expect this field to be set by schedulers. Why is it not set by default scheduler, but apiserver? How does apiserver know which scheduler does the work, if there are more than one? Letting DaemonSet controller set this field sounds reasonable, as DaemonSet controller is the "scheduler".
is introduced by multi-scheduler; a common case is to set it by user in : it means this Pod should be scheduled by specific scheduler. In each scheduler (including the default scheduler), it will check whether it's responsible for the pending Pod. The default value is default scheduler :) Sure, I'll open a PR for this :)
/assign
Isn't scheduler name ignored when spec.nodeName is set?
no, right now; that makes sense, I'll also include this in PR :)
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity.

Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
gotFitErr, gotOK := err.(*framework.FitError) wantFitErr, wantOK := test.wErr.(*framework.FitError) if gotOK != wantOK { <del> t.Errorf("Expected err to be FitError: %v, but got %v", wantOK, gotOK) </del> <ins> t.Errorf("Expected err to be FitError: %v, but got %v (error: %v)", wantOK, gotOK, err) </ins> } else if gotOK { if diff := cmp.Diff(gotFitErr, wantFitErr); diff != "" { t.Errorf("Unexpected fitErr: (-want, +got): %s", diff)

Discussion:
When Extender filters out some Nodes, we don't set any unschedulable plugins at all. It means Extender is completely ignored during the requeueing process. So, what's happening is: If Extender filters out all Nodes during scheduling, this Pod is soon retried because this Pod doesn't have any plugin name in unschedulable plugins. If Extender filters out some Nodes during scheduling and plugins filter out all other Nodes, this Pod is retried based on plugins' QueueingHint. Even if any cluster events happen and it could change Extender's decision (but not any plugins' decision), this Pod won't be requeued to activeQ/backoffQ. The latter case is serious because it could make Pods being stuck in unschedulable pod pool in 5min. We should have a short-term solution for the latter case. We can requeue Pods, which were rejected by Extender, by any kind of cluster events because we cannot know which events make Pods schedulable. Eventually, this issue makes us wonder how Pods rejected by Extender should be requeued. We cannot implement QHint equivalent in Extenders because it'd be too slow to call Extender every time any cluster events happen. Probably, somehow implementing EventsToRegister equivalent in Extender? Use Extender which does something in Filter. No response master <detailsn/a </details<details</details<details</details<details</details<details</details
/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 scheduling
/reopen We'll close it when all cherry-picks are done.
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
/close Cherry-picks are done.
Change:
<ins> apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example spec: backend: serviceName: default-backend servicePort: 80 rules: - http: paths: - path: /testpath backend: serviceName: test servicePort: 80 </ins>  No newline at end of file

Discussion:
What happened: Tried to convert a v1beta1 Ingress object to v1, and received the following error: What you expected to happen: The conversion to work. How to reproduce it (as minimally and precisely as possible): Then run: /sig cli /assign
Can i work on this issue?
/assign
/triage accepted
Change:
"//pkg/api/v1:go_default_library", "//pkg/apis/extensions/v1beta1:go_default_library", "//pkg/client/clientset_generated/clientset:go_default_library", <ins> "//pkg/cloudprovider:go_default_library", </ins> "//test/e2e/chaosmonkey:go_default_library", "//test/e2e/common:go_default_library", "//test/e2e/framework:go_default_library",

Discussion:
In federation tests, if we observe the build logs. we see cleaning up LoadBalancer from cloud provider seems not working. It has 2 effects: delays the tests by waiting to delete but always returns error. so we waste like 5 minutes. maybe we are leaking the LoadBalancer in the project.
we can see these errors in every build. but just for reference here are some build logs https://k8s-
cc
All the errors in logs are . It doesn't necessarily indicate we are leaking resource, just now we must have clusterID initialized before calling EnsureLoadBalancerDeleted(). Would be better to not call this function directly in e2e test :)
Federation cleanup should use the same implementation as non-federated e2e test:
function looks like only specific to GCE. in future we would run the e2e tests in AWS too. it would be better to use generic functions if any.
using is working for us. here is the test logs https://k8s-
EnsureLoadBalancerResourcesDeleted() actually cleans up nothing, it only lists forwarding rules and probably logging :)
Change:
events, _ = dd.client.CoreV1().Events(namespace).Search(scheme.Scheme, d) } <del> return describeDeployment(d, selector, d, events, dd) </del> <ins> return describeDeployment(d, selector, d.DeepCopy(), events, dd) </ins> } func describeDeployment(d *appsv1.Deployment, selector labels.Selector, internalDeployment *appsv1.Deployment, events *corev1.EventList, dd *DeploymentDescriber) (string, error) {

Discussion:
Create a deployment as described in section, and run 'kubectl describe deploy/testWhat happened: shows , while shows the current replicaset infomation What you expected to happen: shows the current replicaset infomation, while shows How to reproduce it (as minimally and precisely as possible): Create a deployment as follows, and wait its pod started. Then, run 'kubectl describe deploy/test Anything else we need to know?: Environment: Kubernetes version (use ): kubectl of 1.14+(I did not try older versions) 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 cli
/assign
Ok, can confirm here. With the old code, during a rollout the data is shown at OldReplicaSets (both the old and new RS) while with the patch during the rollout the NewReplicaSet contains the net one and the Old the old one ( obvious here) while the old exists. I'll make some more tests here and check if is there anything else in your PR that needs better verification, otherwise wer can follow with it! Thank you!
/triage accepted
Change:
// being upgraded, then the container runtime must also support the initially // selected version or the redial is expected to fail, which requires a restart // of kubelet. <del> func (r *remoteImageService) determineAPIVersion(conn *grpc.ClientConn) error { </del> <ins> func (r *remoteImageService) determineAPIVersion(conn *grpc.ClientConn, endpoint string) error { </ins> ctx, cancel := getContextWithTimeout(r.timeout) defer cancel()

Discussion:
When installing the latest component, got the error: Then the flag , got error: It is confusing to see these error msgs at the first glance, need to make it more clearly. Add the required field validation, and add more supportive error message. Download the latest v1.25.0 binary, and install it with systemd service or just manually start the binary, will reproduce these errors. <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
/sig node
kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions /close
Closing this issue. <detailsIn response to : kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions 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
Yes, I got to know the , so need to add runtime validation by the fix PR: PTAL thanks.
Change:
SRCS=sampledeviceplugin ARCH ?= amd64 TARGET ?= $(CURDIR) <ins> GOARM ?= 7 </ins> GOLANG_VERSION ?= latest SRC_DIR = $(notdir $(shell pwd)) export

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: Building the image binaries requires the GOARM variable to be set. Because it is not defined in all Makefiles, cannot the image binaries for the images in question. What you expected to happen: should succeed. How to reproduce it (as minimally and precisely as possible): git clone cd kubernetes/test/images/entrypoint-tester make Anything else we need to know?: Environment: N/A Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig testing
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .

/lifecycle stale
/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
Change:
pods = filterHostPortConflicts(pods) ch := make(chan RunPodResult) <del> for _, pod := range pods { </del> <ins> for i := range pods { pod := pods[i] // Make a copy </ins> go func() { info, err := kl.runPod(pod) ch <- RunPodResult{&pod, info, err}

Discussion:
For example: struct field tag not compatible with reflect.StructTag.Get missing argument for Errorf("%v"): format reads arg 2, have only 1 args range variable pod enclosed by function struct field tag not compatible with reflect.StructTag.Get arg minion for printf verb %s of wrong type: unreachable code unreachable code
Those all look really important
I'm going to fix this unless I hear that someone else is working on this in the next couple minutes.
Change:
return expClient.Deployments(ns).DeleteCollection(nil, api.ListOptions{}) } <ins> func deleteReplicaSets(expClient extensions_unversioned.ExtensionsInterface, ns string) error { return expClient.ReplicaSets(ns).DeleteCollection(nil, api.ListOptions{}) } </ins> func deleteIngress(expClient extensions_unversioned.ExtensionsInterface, ns string) error { return expClient.Ingresses(ns).DeleteCollection(nil, api.ListOptions{}) }

Discussion:
The delete command for a replicaset hangs forever. This then manifests as phantom RSs when I delete and recreate a namespace.
- delete is the gift that keeps on giving
cc
Had you already deleted the corresponding Deployment?
I am still seeing this problem. Deployments and replica sets are sticking.
From what I can tell, calling DELETE_COLLECTION on Deployments is returning: And since the controller assumes not found errors are equivalent to already deleted, it thinks the content is deleted. When I manually inspect, I still see the deployment and replica set laying around... //cc
holding on this while i debug some more...
This was a false alarm, apologies.
Change:
"Time": recent(maxStatsAge), // We don't limit system container memory. "AvailableBytes":  BeNil(), <del> "UsageBytes":      bounded(1*framework.Mb, 10*framework.Gb), "WorkingSetBytes": bounded(1*framework.Mb, 10*framework.Gb), </del> <ins> "UsageBytes":      bounded(1*framework.Mb, memoryLimit), "WorkingSetBytes": bounded(1*framework.Mb, memoryLimit), </ins> // this now returns /sys/fs/cgroup/memory.stat total_rss <del> "RSSBytes":        bounded(1*framework.Mb, 1*framework.Gb), </del> <ins> "RSSBytes":        bounded(1*framework.Mb, memoryLimit), </ins> "PageFaults":      bounded(1000, 1E9), "MajorPageFaults": bounded(0, 100000), }),

Discussion:
/kind bug What happened: e2e node summary test fails on machines with more than 10Gb of ram. What you expected to happen: memory limit bounds to look at node capacity rather than hardcode an upper bound. How to reproduce it (as minimally and precisely as possible): have more ram on a box and run e2e-node FOCUS=Summary Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig node
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/kubernetes/pkg/api/testapi" "k8s.io/kubernetes/pkg/api/v1" <del> "k8s.io/kubernetes/pkg/apis/extensions" </del> <ins> extensions "k8s.io/kubernetes/pkg/apis/extensions/v1beta1" </ins> ) func newPod(podName string, nodeName string, label map[string]string) *v1.Pod {

Discussion:
Here are the hash label keys of all controllers: Deployment: DaemonSet: (new in 1.7) StatefulSet: (new in 1.7) Had a brief discussion with and about this, it should be consistent. We can use for DaemonSet and StatefulSet, and keep Deployment as-is. Deployment hash label key should be different from other two because Deployment pods hash labels is used by selector (unlike the other two controllers). We probably should have used hash annotations instead of hash labels for DaemonSet and StatefulSet, since we don't use hash labels to select their history or pods. Hash labels are chosen for consistency. This is fine since we don't modify hash label values.
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
Actually, controller revisions created by statefulset, daemonset has different label: // controller revision created by statefulset label: "" // controller revision created by daemonset label: controller-revision-hash: "" should be consistent?
Change:
funcOut = file } <del> docsForTypes := pkg_runtime.ParseDocumentationFrom(*typeSrc) </del> <ins> docsForTypes := kruntime.ParseDocumentationFrom(*typeSrc) </ins> if *verify == true { <del> rc, err := pkg_runtime.VerifySwaggerDocsExist(docsForTypes, funcOut) </del> <ins> rc, err := kruntime.VerifySwaggerDocsExist(docsForTypes, funcOut) </ins> if err != nil { fmt.Fprintf(os.Stderr, "Error in verification process: %sn", err) }

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
Requests: podRes, Limits:   podRes, }, <del> }) </del> <ins> }, framework.PodStartShortTimeout) </ins> defer func() { // Clean-up the critical pod

Discussion:
Which jobs are flaking: sig-release-master-blocking Conformance - GCE - master Which test(s) are flaking: E2E: [sig-scheduling] SchedulerPreemption [Serial] validates basic preemption works [Conformance] Testgrid link: Reason for failure: Anything else we need to know: is currently unavailable links to specific failures in spyglass appreciated From TestGrid alert ...
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
I cannot spot any significant logic flaw in the test. A possible cause is the timeout is set too short (1 minute), which may be not enough for the terminating pod to run. Notice that unlike integration test, the time includes the end to end cycle: (1) preemptor being scheduled and evict low-priority pods, (2) low-priority pods being terminating -reported by kubelet that the victims have been deleted, (3) scheduler gets notifications from API server that the victims have been deleted, (4) preemptor gets scheduled, (5) kubelet reports the preemptor is running. /cc for more thoughts.
Maybe, some logs to / would help. Just making the timeout longer don't make sense.
Is addressing this flake?
I think this flake happens before the failure tries to fix:
/kind flake
That's indeed a lot of steps, and flakiness seems very low. I think increasing the timeout for preemption seems reasonable.
is this flake a must-fix in 1.20?
Change:
# See the OWNERS docs at https://go.k8s.io/owners <ins> # Disable inheritance as stable metrics require SIG Instrumentation approval options: no_parent_owners: true </ins> approvers: - sig-instrumentation-approvers reviewers: - sig-instrumentation-reviewers labels: - sig/instrumentation <ins> - area/stable-metrics </ins>

Discussion:
Currently, stable metric changes can be approved by top-level approvers and are not obviously "special" to a contributor. We have verify scripts that will prevent adding or changing stable metrics without updating Instrumentation-owned files, but the errors can easily be "fixed" by running the corresponding update script. Contributors may end up doing so to fix the verify errors and not understand the consequences of promoting a metric to "stable" status. We would like to consider the following: [x] Migrate the documentation for stable metrics from KEP to the community/developer docs: [x] Add a new label that flags stable metrics changes, ex. , from the OWNERS file in required for stable metrics [x] When the label is applied, a comment from the bot that alerts contributors of the stable metric guidelines, similar to [ ] Do we also want to consider adding to the stable metrics OWNERS file to avoid accidental merges from top-level approvers? We had some contributors join the latest SIG Instrumentation meeting requesting to add some labels to stable metrics. They were under the impression that stable metrics worked similar to other Kubernetes APIs, and thus they could make "compatible" API changes. This is not the case, and they were unaware of the stable metrics documentation. I think it would be good to flag this documentation to anyone making stable metrics changes, in the same way that we flag API changes and point contributors to that documentation. /sig instrumentation contributor-experience /cc
I don't think we had any issue with top-level approvers graduating metrics to stable in the past, but I also don't think they should be able to do that, so I would be in favor of that change.
Related, stable metrics changes should some day trigger a docs PR to update a reference doc. (there's no reference doc listing stable metrics yet, but I hope that changes)
/triage accepted
/assign ehashman