jiebi/CodeConvo huggingface dataset:
Change:
} else if err != nil { t.Errorf("%d: expected nil error, got %v", i, err) } <del> if !reflect.DeepEqual(*v.value, test.expected) { t.Errorf("%d: expected %+v, got %+v", i, test.expected, *v.value) </del> <ins> if !reflect.DeepEqual(s, test.expected) { t.Errorf("%d: expected %+v, got %+v", i, test.expected, s) </ins> } if v.changed != test.changed { t.Errorf("%d: expected %t got %t", i, test.changed, v.changed)

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 --, is not assigned is assigned Use to parse the command line parameters I am preparing to merge pr to solve this problem 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 cloud-provider /area provider/gcp
/area test
how about 'flags.VarP('
The pointer of 's values is assigned to the new address, and the relationship with the input parameter is broken. The 'flags.VarP(' also to no avail
/assign /triage accepted
Change:
- github.com/coreos/pkg: [399ea9e](https://github.com/coreos/pkg/tree/399ea9e) - github.com/dgrijalva/jwt-go: [v3.2.0+incompatible](https://github.com/dgrijalva/jwt-go/tree/v3.2.0) - github.com/google/martian: [v2.1.0+incompatible](https://github.com/google/martian/tree/v2.1.0) <del> - github.com/jpillora/backoff: [v1.0.0](https://github.com/jpillora/backoff/tree/v1.0.0) </del>  No newline at end of file <ins> - github.com/jpillora/backoff: [v1.0.0](https://github.com/jpillora/backoff/tree/v1.0.0) </ins>

Discussion:
It looks like default HTTPS port for kube-scheduler has changed from to between 1.22.4 and 1.23.0 releases and it has not been mentioned in the changelog. EDIT: Actually, I see now that 1.22.4 listens on , but also on and 1.23.0 just stopped listening on . Breaking changes to be included in the changelog. With kube-prometheus-stack installed, with kube-scheduler scraping configured, upgrade kube-scheduler from 1.22.4 to 1.23.0. No response <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
/sig release scheduling
was the change, and included a detailed release note. Did that not get pulled into the release notes automatically? /sig docs release
can you help update the 1.23 release notes with the content from in the "Action required" section?
/assign ingvagabund
I see now that it has indeed been mentioned for , here: but not for .
weird, v1.23.0 is supposed to roll up all the intermediate notes.
Is it sufficient to manually edit and extend
manual edit is fine, hoist it to the section
Change:
if cloud.ProviderName() != openstack.ProviderName { return nil, fmt.Errorf("Expected Openstack cloud, found %s", cloud.ProviderName()) } <ins> openstackCloud, ok := cloud.(*openstack.OpenStack) if ok && openstackCloud.NodeVolumeAttachLimit() > 0 { volumeLimits[util.CinderVolumeLimitKey] = int64(openstackCloud.NodeVolumeAttachLimit()) } </ins> return volumeLimits, nil }

Discussion:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Change:
continue } <del> // Ensure it is the expected function if reflect.ValueOf(cCmd.Args).Pointer() != reflect.ValueOf(args.args).Pointer() { t.Error("The function pointers where not equal.") } </del> // Test passing argument set err := cCmd.Args(cCmd, args.pass) if err != nil { t.Errorf("command %s should validate the args: %vn %v", cCmd.Name(), args.pass, err) }

Discussion:
fails with the latest Go 1.21 dev branch, with: Test should pass but it fails. Build the latest Go tree from source (or wait for Go 1.21 rc1). Then run: FORCEHOSTGO=y make test WHAT=./cmd/kubeadm/app/cmd/phases/workflow This test is in . It is comparing function pointers by using reflect on the function value and then checking .Pointer. This typically does work for ordinary functions, but the test is comparing closures instead. If the closures were created by calling the same function twice, they may be different closures. This is why Go does not support function equality directly at all (which is why the test is resorting to reflect and non-guaranteed behavior). The closures appear to come from, among other places, cobra.ExactArgs: The Kubernetes test itself needs to be rewritten not to depend on function pointer equality. In fact, as the comment notes, in the earlier Go implementation, checking .Pointer made it appear that ExactArgs(1) == ExactArgs(3), because Pointer only looks at the code pointer, not the associated data pointer: The test is already running the function to test that it behaves correctly. The Pointer comparison should simply be deleted. Happens at HEAD and in v1.27.1. N/A Linux, irrelevant. N/A N/A N/A
thanks for logging the issue makes sense! /assign /area kubeadm /sig cluster-lifecycle
/triage accepted
fix is here:
Added fix PR reference to to ensure it gets backported so release branches can pick up go1.21
Change:
const ( SchedulerAnnotationKey = "scheduler.alpha.kubernetes.io/name" <ins> initialGetBackoff      = 100 * time.Millisecond maximalGetBackoff      = time.Minute </ins> ) // ConfigFactory knows how to fill out a scheduler config with its support functions.

Discussion:
If the first scheduling failed (whatever the reason is), the Error() func is called. However, the default Error function is wrong and in case of some errors may drop the pod and never requeue it for scheduling again. The problem is that if the Get() function: return an error (for me it was "dial tcp 127.0.0.1:8080: connect: cannot assign requested address", but it doesn't really matter), then we simply forget about a pod and will never schedule it again. We should retry those requests (with some backoff).
Change:
} if !bFoundDisk { <del> return nil, fmt.Errorf("detach azure disk failure, disk %s not found, diskURI: %s", diskName, diskURI) </del> <ins> // only log here, next action is to update VM status with original meta data klog.Errorf("detach azure disk: disk %s not found, diskURI: %s", diskName, diskURI) </ins> } newVM := compute.VirtualMachine{

Discussion:
What happened: made sure that API calls to Azure that return a HTTP code 200 with an embedded error are retried. Nevertheless, we observe a series of errors during the Azure Disk detach backoff while calling , and the detach operation is immediately cancelled. Happy scenario: the disk is to be re-attached to the same VM. The reconciler's will update the VMSS instance and the previous detach error will be masked. It takes 15 min for the detach call to timeout but the disk will eventually get re-attached after several VMSS updates (). Not-so-happy scenario: the disk is to be re-attached to another VM. The same errors as in will be thrown indefinitely. controller-manager's logs: What you expected to happen: The backoff succeeds and the failed detach operation gets retried. How to reproduce it: A single Pod with a single Azure Disk. This seems quite hard to reproduce, but it is happening consistently in one of our customer's resource group (eastus). Anything else we need to know?: Environment: Kubernetes version: branch (kubernetes/kubernetes Cloud provider: Azure (via AKS-Engine) OS: Ubuntu 16.04.6 LTS Kernel: 4.15.0-1042-azure Install tools: Network plugin and version: Others: /sig azure paging
/assign
Change:
- source: /kubernetes-vagrant/network_closure.sh - require: - pkg: docker-io <ins> - sls: kubelet </ins> - cwd: / - user: root - group: root

Discussion:
Self-assigning as I work out a reliable fix.
cc
Running into a few issues. On GCE, did you guys block somewhere to wait for etcd to be running before reporting success on kube-up?
No, except there is a race between addson services, dns and etcd container. We introduced a retry logic on those services.
I assume pulling the image is just so fast that you don't run into e2e errors, it looks like you guys block on wait-for-minions that uses glcloud, so I guess when minions are reported in etcd, then you know you are good...
Change:
} lun := strconv.Itoa(iscsi.Lun) <ins> portal := portalBuilder(iscsi.TargetPortal) </ins> return &iscsiDiskBuilder{ iscsiDisk: &iscsiDisk{ podUID:  podUID, volName: spec.Name(), <del> portal:  iscsi.TargetPortal, </del> <ins> portal:  portal, </ins> iqn:     iscsi.IQN, lun:     lun, manager: manager, <del> mounter: mounter, </del> <ins> mounter: &mount.SafeFormatAndMount{mounter, exec.New()}, </ins> plugin:  plugin}, fsType:   iscsi.FSType, readOnly: readOnly,

Discussion:
Documentation says that port number for is optional, but I've found that not to be true. It's due to the way it detects whether the disk is attached or not. also must be an IP. Refer to:
/cc
I see what you meant. Good catch. According to , the disk path contains both ip and port. So port is indeed required even for default port 3260. If you don't have a pr yet, I'll provide a fix to the doc.
I don't have a CLA in file yet, so I'll leave it up to you. Thanks.
check this out
Change:
default: // We lost the lock. klog.ErrorS(nil, "Leaderelection lost") <del> os.Exit(1) </del> <ins> klog.FlushAndExit(klog.ExitFlushTimeout, 1) </ins> } }, }

Discussion:
kube-controller-manager yields whole stack trace when it loses leaderelection. kube-controller-manager to only log and to exit (without logging 17K lines of stack trace that is not useful for anyone). kube-controller-manager yields around 17K lines of stack trace (omitted in the above example). No response <detailsv1.20.12 </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/assign /triage accepted
has Fatalf always triggered a stack dump of all goroutines?
/cc
Seems like does a dump of all goroutines Could we and then maybe? /cc in case you have thoughts about this
If I read the right, it only printed the current goroutine to stderr. Dumping everything seems to have been later. make sense to me.
Dumping of all goroutines was in
I have similar doubts. I want to fix it. /assign
kube-scheduler seems to have a similar issue (but a shorter stack trace)
When replacing (useful because it doesn't do structured logging, not just because of the stack trace problem), remember to use + the new . Updated migration instructions are pending in There's also - reverting the klog change might be a faster way to address this.
Change:
if err != nil { framework.Failf("Failed to list all dns service pods") } <del> if len(dnsPods.Items) != 1 { framework.Failf("Unexpected number of pods (%d) matches the label selector %v", len(dnsPods.Items), dnsServiceLabelSelector.String()) </del> <ins> if len(dnsPods.Items) < 1 { framework.Failf("No pods match the label selector %v", dnsServiceLabelSelector.String()) </ins> } framework.ExpectNoError(framework.WaitForPodRunningInNamespace(f.Client, dnsPods.Items[0].Name, api.NamespaceSystem)) }

Discussion:
everything with is now failing, likely after 2021-11-04 17:44 PDT No response /sig node
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
The best course of actions is likely just remove those tests from the job, similar to
Change:
"//pkg/registry/generic/registry:go_default_library", "//pkg/runtime:go_default_library", "//pkg/storage:go_default_library", <ins> "//pkg/util/wait:go_default_library", </ins> ], )

Discussion:
What happened: When I try to test after implementing the 1st approach according to , I found pod disruption budgets cannot handle concurrent requests. The error message is: It is an Optimistic Lock error message. It means PDB can't handle concurrent requests. How to reproduce it (as minimally and precisely as possible): 1) Create a deployment with 6 replicas and schedule them to the same node, say node A. You can leave only one node scheduling enabled, and then create the deployment. 2) Create the PDB that match the deployment's label 3) Uncordon another node, say node B 4) Drain node A using concurrent POST eviction requests. Ref: I'm not sure if this behavior is OK for PDB. I think I can make work by waiting for a while if current pod label(s) match previous pod label(s).
Oh, that's interesting. I think the problem is that this function doesn't retry if UpdateStatus() fails due to version conflict. I think the solution is to modify the caller, i.e. this function so that instead of just it instead does something like This will loop re-doing checkAndDecrement() and getPodDisruptionBudgets() until checkAndDecrement() succeeds, or fails with a non-conflict error. Does that make sense? cc/ for sanity check
Or use PATCH?
Yes, PATCH should work also. I haven't written code that uses PATCH, so I can't advise exactly the code to write here (there are examples by grepping for patch, but I'm not sure exactly what is the right way to do it from inside of API server code, which is where we are here). can you do a PR to implement this, either using the approach I described above or using PATCH? I think this is important to get into 1.5.
I think PATCH may NOT be safe here. For example: 1) current pdb 2) creating eviction A: get 3) creating eviction B: get 4) creating eviction A: PATCH pdb 5) creating eviction B: PATCH pdb 6) pdb's . It's wrong. Retry loop make more sense to me.
Good point! You're right. Retry loop should be OK.
I can help to create a PR using retry loop.

Could you please triage this for 1.5 and apply blocker or non-blocker labels as appropriate along with priority.
Done.
who is actually working on this issue? Could one of you set yourselves as an assignee for this issue? Thanks! cc:
retry logic with PR needs reviews/lgtm
Change:
return err } default: <del> return fmt.Errorf("pod %v state wasn't added but get updated", key) </del> <ins> return fmt.Errorf("pod %v is not added to scheduler cache, so cannot be updated", key) </ins> } return nil }

Discussion:
/kind bug There are several error messages in the scheduler cache that are confusing to read, at least one of these surfaced up to end users via Events. I noticed these two in particular but there may be others: Whether or not these should actually be surfacing as events, the messages should be cleaned up.
cc
Seems that these are internal or implement details in scheduler, do our end users can fully understand what the events really mean? I think it is depend on our own implement. idea?
I believe, the problem is with in the message but I am not able to reproduce it, can you please share steps to reproduce this.
No unfortunately, one of our users reported seeing it when there system was in a bad state, not in a reproducible way. The point of the issue is just that the grammar in those messages is bad, which should be fixable even if you can't get them to fire.
Change:
// resourceVersion may be used to specify what version to begin watching, // which should be the current resourceVersion, and no longer rv+1 // (e.g. reconnecting without missing any updates). <ins> // If resource version is "0", this interface will list current objects directory defined by key // and send them in "ADDED" events, before watch starts. </ins> WatchList(ctx context.Context, key string, resourceVersion string, p SelectionPredicate) (watch.Interface, error) // Get unmarshals json found at key into objPtr. On a not found error, will either

Discussion:
Currently, Watch request with resourceVersion=0 results in: returning a single "watch event" for every object existing "now" starts watching from that point This is pretty misleading (e.g. it's different that what we have in etcd, where there is no first step from above). In the v2 api, we should probably eliminate the first stop (or even disallow watch requests with resourceVersion = 0).
/cc
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
/remove-lifecycle rotten /lifecycle frozen
What do you mean by v2 API? Are we ever going to have a v2 of the machiery and semantics?
In 2015 I thought it's not ridiculous. I'm not sure I believe in it now. Moreover, with we will actually be taking benefits of semantic like this, so we should close this.
Change:
podIndexLabelDisabled:  true, expectedReady:          ptr.To[int32](0), }, <ins> "FailureTarget=False condition added manually is ignored": { jobPodFailurePolicy: true, parallelism:         1, completions:         1, activePods:          1, readyPods:           1, initialStatus: &jobInitialStatus{ active: 1, startTime: func() *time.Time { now := time.Now() return &now }(), conditions: []batch.JobCondition{ { Type:    batch.JobFailureTarget, Status:  v1.ConditionFalse, Reason:  "ConditionAddedManually", Message: "Testing", }, }, }, expectedActive: 1, expectedReady:  ptr.To[int32](1), expectedConditions: []batch.JobCondition{ { Type:    batch.JobFailureTarget, Status:  v1.ConditionFalse, Reason:  "ConditionAddedManually", Message: "Testing", }, }, }, </ins> } for name, tc := range testCases {

Discussion:
When the FailureTarget=False condition is manually, then the Job terminates. The condition should be ignored by the Job controller. the like this: the following script to repro: Issue: the Job gets terminated with the status like this: No response <details</details<detailsKind </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
/cc
/assign Thanks!
/sig apps
Change:
v1 "k8s.io/api/core/v1" storagev1 "k8s.io/api/storage/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/apimachinery/pkg/watch" utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/client-go/informers"

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: There are some places in that wait for conditions . We should update all the places to set something like /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- 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! --What happened: There are some places in that wait for conditions . We should update all the places to set something like /good-first-issue 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
/kind cleanup /remove-kind bug
I can try to fix this :) /assign
/sig storage
Change:
--secure-port=443  --basic-auth-file=/srv/kubernetes/basic_auth.csv  --target-ram-mb=$((${NUM_NODES} * 60))  <del> --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota  </del> $(cat apiserver_flags) &> /var/log/kube-apiserver.log & # kube-contoller-manager now needs running kube-api server to actually start

Discussion:
Until is fixed (which won't happen before code-freeze is finished), kubemark-scale will be failing/timing-out and this is "working-as-intended" until then. It should be possible to switch off secrets in kubemark to make other problems debuggable. For now we would like to: switch off secrets in kubemark-scale leave them in all other kubemark suites
can you add a release-blocking or non-blocking label to this issue?
Is kubemark scale useful/realistic if it disables things that are required in actual deployments?
We use it for development, and we need a way to switch off particular parts.
- it's just a short term fix that would allow to fix/debug different problems at the same time (we already know that secrets are causing problems and we will be fixing it).
To clarify - I'm not going to leave that forever - as soon as we will have some fix for secrets in, we will enable it back in 5000-node kubemark. Currently because of secrets those tests doesn't bring any value.
Also - this one is already done.