jiebi/CodeConvo huggingface dataset:
Change:
w.Write(LEVEL_1, "ResourcetRequeststLimitsn") w.Write(LEVEL_1, "--------t--------t------n") reqs, limits := getPodsTotalRequestsAndLimits(nodeNonTerminatedPodsList) <del> cpuReqs, cpuLimits, memoryReqs, memoryLimits := reqs[api.ResourceCPU], limits[api.ResourceCPU], reqs[api.ResourceMemory], limits[api.ResourceMemory] </del> <ins> cpuReqs, cpuLimits, memoryReqs, memoryLimits, ephemeralstorageReqs, ephemeralstorageLimits := reqs[api.ResourceCPU], limits[api.ResourceCPU], reqs[api.ResourceMemory], limits[api.ResourceMemory], reqs[api.ResourceEphemeralStorage], limits[api.ResourceEphemeralStorage] </ins> fractionCpuReqs := float64(0) fractionCpuLimits := float64(0) if allocatable.Cpu().MilliValue() != 0 {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : display EphemeralStorage usage with 'kubectl describe node' , like; Why is this needed: ephemeral-storage is a standard ContainerResources like CPU and Mem now. but now we don't display it in the node state. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature /sig cli cc
Change:
- Score: 2 Utilization: 1 `), <del> wantErr: `decoding .profiles[0].pluginConfig[0]: decoding args for plugin NodeResourcesFit: strict decoding error: unknown field "scoringStrategy.requestedToCapacityRatio.shape[0].Score", unknown field "scoringStrategy.requestedToCapacityRatio.shape[0].Utilization"`, </del> <ins> wantErr: `strict decoding error: decoding .profiles[0].pluginConfig[0]: strict decoding error: decoding args for plugin NodeResourcesFit: strict decoding error: unknown field "scoringStrategy.requestedToCapacityRatio.shape[0].Score", unknown field "scoringStrategy.requestedToCapacityRatio.shape[0].Utilization"`, </ins> }, { name: "v1beta3 NodeResourcesFitArgs resources encoding is strict",

Discussion:
With the addition of server side validation in 1.23, it is now possible for a call to successfully decode it’s data and return a non-nil error when there are strict decoding errors (e.g. duplicate/unknown fields). This means that callers of can distinguish between fatal errors (that cause decoding to fail) and strict decoding errors (that still allow the decode to succeed) by inspecting the target object (to see if it was successfully decoded into) and the error itself (to see if it is a ) With the NestedObjectDecoder however, it only returns an error from giving no indication whether a strict decoding error it has returned comes from an internal decode step that short circuited (by not accounting for strict decoding errors) or actually did successfully decode, but also encountered strict decoding errors. We propose taking a few actions to minimize the possibility of erroneous short-circuiting from Document how all nested decoders should only return strict decoding errors if all decoding is successful or return only non-strict decoding (ie. fatal errors). Document this for all known in-tree and out-of-tree . Update in-tree nested decoders to do the above mentioned behavior (which is just the kube-scheduler) Long-term solutions to better guarantee that no erroneous short-circuiting is taking place could include deprecating the current interface in favor of one that returns both the target object that was decoded into along with an error return a special error type specific to indicating that all internal decoding was successful.
/sig api-machinery
/triage accepted
Change:
The address for the proxy server to serve on (set to 0.0.0.0 or "" for all interfaces) .PP <del> fB-configfilefP="/tmp/proxy_config" Configuration file for the proxy .PP </del> fB-etcd_serversfP=[] List of etcd servers to watch ( [la]http://ip:port[ra]), comma separated (optional)

Discussion:
It's not well tested nor widely used; so it should either be removed or have tests and uses .
Change:
local network=$(make-gcloud-network-argument  "${NETWORK_PROJECT}"  "${REGION}"  <del> "${NETWORK}" </del> <ins> "${NETWORK}"  </ins> "${SUBNETWORK:-}"  ""  "${ENABLE_IP_ALIASES:-}" 

Discussion:
The following that have been failing on our 5k-node tests (https://k8s-): [HPA] Horizontal pod autoscaling (scale resource: CPU) [sig-autoscaling] ReplicationController light Should scale from 1 pod to 2 pods [HPA] Horizontal pod autoscaling (scale resource: CPU) [sig-autoscaling] ReplicationController light Should scale from 2 pods to 1 pod This is part of the correctness suite and large cluster tests are release-blocking. cc
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/autoscaling sig/scalability: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Could you PTAL into this or redirect as apt? It's a release-blocker.
xRef
The tests seem to be passing on the normal correctness job - https://k8s- (except the latest run) but they're failing on large cluster and the reason seems to be timeout waiting for scaling to happen.
If i have to guess it is heapster who is failing to provide metrics. HPA itself has no direct dependency on the number of nodes in the cluster. Assigning to .
is going to take a look.
From the logs it seems like Heapster is unable to get metrics from nodes. It appears to be a separate issue from addon resizer restarts.
Thanks for checking it. I have got the same logs for smaller cluster (10 nodes), so at least we know that the problem is not related to big number of nodes/pods.
- I'm seeing the test pass on our regular (small cluster) gce job - https://k8s- And seems like it was passing before and then started failing on our 2k-node job - https://k8s-
thanks for pointing on it. The main difference between runs on small and big cluster - special node that we are creating for heapster container. And my local experiment have shown that without this node everything works, but with it - fails.

So I assume that it's more network related. I'll try to figure out what's going on.
Removing this as release-blocker and downing the priority as it's a setup issue specific to use of heapster node. Would continue to work on it (thanks!).
Change:
eventType = v1.EventTypeWarning } expc.recorder.Event(pvc, eventType, events.ExternalExpanding, fmt.Sprintf("Ignoring the PVC: %v.", msg)) <del> klog.Infof("Ignoring the PVC %q (uid: %q) : %v.", util.GetPersistentVolumeClaimQualifiedName(pvc), pvc.UID, msg) </del> <ins> klog.Infof("Ignoring the PVC %q (uid: %q) : %v.", key, pvc.UID, msg) </ins> // If we are expecting that an external plugin will handle resizing this volume then // is no point in requeuing this PVC. return nil

Discussion:
I migrated an existing EBS volume from in-tree plugin to external aws-ebs-csi-driver (). Resizing PVC twice in 6 hour window causes kube-controller-manager to crash. Exception message: Kube-controller-manager shouldn't crash in such case. If external aws-ebs-csi-driver fails to provision the pvc it should just log an warning or error and continue operating as usual running cluster version 1.22.9 using in-tree aws ebs driver. pvc: Install aws-ebs-csi-driver following featureGate CSIMigrationAWS on all cluster components (with draining nodes before enabling featureGate on kubelets - according to warning ) we have ebs volume that has been migrated to aws-ebs-csi-driver. pvc by increasing .spec.resources.request.storage to 2Gi. PVC, PV and EBS volume are correctly resized. once again not later than 6 hours after first resize. Increase .spec.resources.request.storage to 3Gi. Now kube-controller-manager throws an exception and crashes: EBS CSI Driver logs: I tried also enabling alpha featureGate InTreePluginAWSUnregister but the issue still occurs. <details</details<detailsAWS </details<details</details<details</details<detailsdocker </details<detailsaws-ebs-csi-driver version 1.10.0 </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 cloud-provider
/sig storage some situation where the sync loop passes a nil parameter to
/assign
SetClaimResizer may return nil pvc and non-nil error, ClaimToClaimKey naively assumes non-nil as described above, will create PR
But the posted bug is I think 1.22 specific and should never happen on master or 1.24 and hence this fix against master is kind of okay and should fix the issue but at the same time code in is still kinda broken in 1.22 because it returns if patching fails.
Change:
"//pkg/client/clientset_generated/release_1_5:go_default_library", "//pkg/client/record:go_default_library", "//pkg/controller:go_default_library", <ins> "//pkg/conversion:go_default_library", </ins> "//pkg/runtime:go_default_library", "//pkg/util/flowcontrol:go_default_library", "//pkg/watch:go_default_library",

Discussion:
Unit tests on PR are failing due to data race in federation-controller/namespace unittest. More logs: https://k8s-
CC
Sent to fix this
Change:
*/ // +k8s:conversion-gen=k8s.io/kubernetes/pkg/apis/batch <ins> // +k8s:conversion-gen=k8s.io/kubernetes/pkg/apis/batch/v1 </ins> // +k8s:conversion-gen-external-types=k8s.io/api/batch/v2alpha1 // +k8s:defaulter-gen=TypeMeta // +k8s:defaulter-gen-input=../../../../vendor/k8s.io/api/batch/v2alpha1

Discussion:
it looks like something is up on master. Clean checkout, touch , then -- produces a delta.
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
That comes out clean. ` That comes out clean. That dir, and who knows how many others, is missing some metadata to allow conversions
looks like it might be the v2alpha1 conversion referencing a v1 type... if the generation processes both the v1 and v2alpha1 packages, it finds the v1 conversion. if it only processes the v2alpha1 package, it doesn't and reverts to the reflection-driven path
this breaks: this works: given a clean build leaves no diff, I think master is fine. the script looks like it doesn't include all required dependencies to rebuild a single package
The tool doesn't know - each pkg i supposed to define enough to make itself hermetic
That are not many input dirs. The generator does not see any custom conversion funcs in v1. As expected, adding v1 to the inputs gives the correct output:
/assign fixed in
Change:
"k8s.io/apimachinery/pkg/util/version" "k8s.io/klog/v2" <ins> "k8s.io/kubernetes/pkg/kubelet/userns/inuserns" </ins> utilkernel "k8s.io/kubernetes/pkg/util/kernel" "k8s.io/mount-utils" )

Discussion:
Everything 2024-05-24 No response /sig testing
/sig node
kubelet logs dmesg:
Seems a regression in
/cc
/triage accepted /priority important-longterm
Change:
} // TODO: needs to check if newMeta==nil && oldMeta !=nil after the repair logic is removed. <del> if newMeta.DeletionGracePeriodSeconds != nil && oldMeta.DeletionGracePeriodSeconds != nil && *newMeta.DeletionGracePeriodSeconds != *oldMeta.DeletionGracePeriodSeconds { </del> <ins> if newMeta.DeletionGracePeriodSeconds != nil && (oldMeta.DeletionGracePeriodSeconds == nil || *newMeta.DeletionGracePeriodSeconds != *oldMeta.DeletionGracePeriodSeconds) { </ins> allErrs = append(allErrs, field.Invalid(fldPath.Child("deletionGracePeriodSeconds"), newMeta.DeletionGracePeriodSeconds, "field is immutable; may only be changed via deletion")) } <ins> if newMeta.DeletionTimestamp != nil && (oldMeta.DeletionTimestamp == nil || !newMeta.DeletionTimestamp.Equal(*oldMeta.DeletionTimestamp)) { allErrs = append(allErrs, field.Invalid(fldPath.Child("deletionTimestamp"), newMeta.DeletionTimestamp, "field is immutable; may only be changed via deletion")) } </ins> // Reject updates that don't specify a resource version if len(newMeta.ResourceVersion) == 0 {

Discussion:
Honestly I'm not sure if this is a bug or a feature, but didn't expect it. Filing this to track.
I think it's a bug. Nothing in the code base depends on it that I can see (edit: namespace deletion does, but only via an in-server call which I'd like to see fixed), and we don't let other delete-related fields mutate during update (deleteGracePeriodSeconds)
Change:
test.fit, test.reasons, test.equivalenceHash, <ins> true, </ins> ) value, ok := ecache.algorithmCache[test.nodeName].predicatesCache.Get(test.predicateKey)

Discussion:
Fix this TODO (raised by : Part of: One thoughts to fix this is, we can redesign the equivalence cache data structure to: bool instead of deleting the entry. certain version tag in the entry, update the version per WRITE op (Update and Invalidate). the version after eCache predicate, and check it before update eCache.
Another possible approach is: eCache before running a predicate. the predicate. the eCache for the predicate. eCache. Basically, in the existing code all predicates are run first and their results are collected and then at the end of the function the eCache is updated. Instead of that, we can move the eCache update for each predicate inside the for loop and next to each predicate execution and synchronize before start of the execution of each predicate. The downside to my suggested approach is that performance may suffer due to frequent locking and unlocking.
Prefer to bsalamat@ 's option which is simpler :). Comparing to performance improvement by eCache, the lock is acceptable to me.
yup same here, going with the locking is easier and is acceptable. - also using a flag for invalidation might just move the problem from eCache to the flag ?
Oh I missed this notification somehow, busy on cleaning scheduler integration test. Yep so if locking is acceptable, it should be cleanest way to fix this, optimistic control would be a more complicated story.
- are you handling this one ?
Already been taken by volunteer days ago :)
Change:
} func RunHelp(cmd *cobra.Command, args []string) { <del> foundCmd, a, err := cmd.Root().Find(args) </del> <ins> foundCmd, _, err := cmd.Root().Find(args) </ins> // NOTE(andreykurilin): actually, I did not find any cases when foundCmd can be nil, //   but let's make this check since it is included in original code of initHelpCmd

Discussion:
PR broke command due to wrong check . Currently, it displays for every command if you do not specify additional arguments(for example will not work, but will).
please looks at this small fix
Change:
### gRPC Probes Graduate to Beta With Kubernetes 1.24, the [gRPC probes functionality](https://github.com/kubernetes/enhancements/issues/2727) <del> has entered beta and is available by default. You can now [configure startup, liveness, and readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for your gRPC app </del> <ins> has entered beta and is available by default. You can now [configure startup, liveness, and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for your gRPC app </ins> natively within Kubernetes, without exposing an HTTP endpoint or using an extra executable. ### Kubelet Credential Provider Graduates to Beta Originally released as Alpha in Kubernetes 1.20, the kubelet's support for <del> [image credential providers](/docs/tasks/kubelet-credential-provider/kubelet-credential-provider/) </del> <ins> [image credential providers](https://kubernetes.io/docs/tasks/kubelet-credential-provider/kubelet-credential-provider/) </ins> has now graduated to Beta. This allows the kubelet to dynamically retrieve credentials for a container image registry using exec plugins, rather than storing credentials on the node's filesystem.

Discussion:
has some broken links. These are relative links that work OK in the release blog article but need to be absolute hyperlinks in the release notes. Links in release notes work. Visit Click on all the links. Specifically, “this guide” in (there are some more, this is one example) No response v1.24.0 n/a n/a n/a n/a n/a
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 and IMO /priority important-soon
Hi Tim, I can help fix this /assign
Change:
if err != nil { return input, err } <del> if len(rights) != 1 { </del> <ins> switch { case len(rights) == 0: continue case len(rights) > 1: </ins> return input, fmt.Errorf("can only compare one element at a time") } right = rights[0].Interface()

Discussion:
On , will fail to evaluate a filter when the member does not exist: For instance, if I were to execute Where not all in that namespace had the annotation, this would fail with the error message: This is confusing as it leads me to think more than one item was selected, so while it is not technically incorrect the error message is misleading. I would furthermore expect to more gracefully handle this case -- a missing here means that the filter should fail, not error.
What do you mean by ? How is it different from ?
As in, don't add that item to the list of items on which the following access is made. When I do: And there is no annotation on , I just get nothing back -- no error, just nothing. Similarly, i would have expected the filtered expression to give me the for all of the pods that have an annotation with value . That, anyway is what I understand the JSONPath syntax to mean. When you write You are saying:
cc since you authored and I'm not sure how we want to fix this.
Taking a look now
it looks like you need to do this (note that the annotations portion is wrapped by ): I wrote a unit test and it worked as expected. PTAL!
I'm pretty sure that was a typo on my end but let me check -- do you have a reproducer script?
I see an entirely different error today... weird:
Ok so you have 1 object with annotations, and 1 without. Let me look into that case.
Let me add another annotation to
No difference if both have annotations:
Ok, I'll have to test using kubectl
I'm the Origin bundled but I don't think there are any patches on JSONPath there:
I'm able to reproduce in the unit test when 1 object has annotations and the other does not, if allowMissingKeys is true for the jsonpath parser.
I see. Let me know if I can be of more help.
I think I have a fix. PR coming soon.
Possible
Change:
}) } <ins> // UpdateVmssVMWithRetry invokes az.VirtualMachineScaleSetVMsClient.Update with exponential backoff retry func (az *Cloud) UpdateVmssVMWithRetry(resourceGroupName string, VMScaleSetName string, instanceID string, parameters compute.VirtualMachineScaleSetVM) error { return wait.ExponentialBackoff(az.requestBackoff(), func() (bool, error) { ctx, cancel := getContextWithCancel() defer cancel() resp, err := az.VirtualMachineScaleSetVMsClient.Update(ctx, resourceGroupName, VMScaleSetName, instanceID, parameters) klog.V(10).Infof("VirtualMachinesClient.CreateOrUpdate(%s,%s): end", VMScaleSetName, instanceID) return az.processHTTPRetryResponse(nil, "", resp, err) }) } </ins> // isSuccessHTTPResponse determines if the response from an HTTP request suggests success func isSuccessHTTPResponse(resp *http.Response) bool { if resp == nil {

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: Current azure cloud provider would fail to detach azure disk when there is server side error, need to add retry mechanism for detach disk operation, while for attach disk operation, it's not necessary since k8s pv-controller will try if first try failed. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.10 ~ master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig azure /assign
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Change:
return nil } <ins> // ResizeController resizes a controller named 'name' by setting replicas to 'replicas' func ResizeController(name string, replicas int, client client.ClientInterface) error { controller, err := client.GetReplicationController(name) if err != nil { return err } controller.DesiredState.Replicas = replicas controllerOut, err := client.UpdateReplicationController(controller) if err != nil { return err } data, err := yaml.Marshal(controllerOut) if err != nil { return err } fmt.Print(string(data)) return nil } </ins> func makePorts(spec string) []api.Port { parts := strings.Split(spec, ",") var result []api.Port

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): HEAD (latest) Environment: dind What happened: Enpoints object is constantly getting updated every 2 seconds, even though nothing has changed in the object. It will produce lot of traffic on any informer watching on endpoints. An update event is produced every 2 second per endpoint. What you expected to happen: Endpoints(any object) should be updated only when there is change in either spec or status. How to reproduce it (as minimally and precisely as possible): Just watch on endpoints Also see the logs from federation controller manager, which is watching on endpoints updates from federated cluster Anything else we need to know: Looking at the endpoints controller code . it looks like reflect.DeepEqual is not working for endpoints labels and Subsets (may be need sorting, just a guess). I also see another issue raised by some time back , related but slightly different. I think this is a bug and if fixed will reduce lot of traffic to etcd.
Those two endpoints specifically are used as shared lock objects by controllers. Agree that's a bad object to use because so many things watch them for updating iptables, etc
code in question:
dupe of
Change:
} // We assume docker return us a list of containers in time order if containerStatus, found := statuses[dockerContainerName]; found { <ins> // Populate last termination state if containerStatus.LastTerminationState.Termination == nil { result := self.inspectContainer(value.ID, dockerContainerName, terminationMessagePath) if result.err == nil && result.status.State.Termination != nil { containerStatus.LastTerminationState = result.status.State } } </ins> containerStatus.RestartCount += 1 statuses[dockerContainerName] = containerStatus continue

Discussion:
Currently kubelet reports current status only. If pod's restart policy is not never, the last terminated container status will be override by the latest status, and lost. We should report last terminated container status. I am going to update our v1beta3 api first, but will hold the implementation until we have
did you have a chance to start working on it? IIUC, to support this we need to change the api (), which IIUC from what wrote in some other thread should be done this week. I'm happy to help with it if you want me to help.
Only breaking changes have a deadline. Additive changes can be done at any time.
I am working on this. PR should be ready today or tomorrow.
Also agree with This is not part of API breakage.
Thanks for answers & clarifications and