jiebi/CodeConvo huggingface dataset:
Change:
// setting up the signing controller. This isn't // actually a problem since the signer is not a // required controller. <ins> klog.V(2).Info("skipping CSR signer controller because no csr cert/key was specified and the default files are missing") </ins> return nil, false, nil default: // Note that '!filesExist && !usesDefaults' is obviously

Discussion:
There are multiple cert controllers that use the same base struct, so when they log, you cannot differentiate which is which.
/sig auth
Change:
defer func() { framework.DeletePodWithWait(f, f.ClientSet, pod) }() <del> err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, time.Minute) </del> <ins> err = framework.WaitForPodRunningInNamespace(f.ClientSet, pod) </ins> Expect(err).To(HaveOccurred(), "while waiting for pod to be running") By("Checking for subpath error event")

Discussion:
Failing Job: These tests started flaking recently (they were consistently green for a long time): Mounted volume expand[Slow] Should verify mounted devices can be resized Volume expand [Slow] Verify if editing PVC allows resize Subpath [Volume type: gcePDPVC] should support restarting containers using file as subpath [Slow] Subpath [Volume type: gcePDPVC] should fail for new directories when readOnly specified in the volumeSource Subpath [Volume type: gcePDPVC] should fail if subpath with backstepping is outside the volume [Slow] Volumes PD should be mountable with ext4 Affected runs: https://k8s- https://k8s- https://k8s- /kind bug /sig storage /priority important-soon /milestone v1.12 /cc - Could you PTAL or delegate? Thanks.
Volume expansion tests have been fixed by
/assign can you investigate the remaining failures?
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 4 days, the issue will be moved out of the v1.12 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Reopening this issue, as a bunch of storage-related e2es started flaking in our large-scale jobs recently: https://k8s- https://k8s- /reopen
I think the latest failures are caused by gce API rate limiting: /assign
It seems to only be failing on scalability test suites. I wonder if it's due to some different cidr configuration
/sig scalability
/kind failing-test
/status approved-for-milestone Friendly ping. This is affecting release-blocking scalability job.
hey what needs to be done here? by whom?
Could you comment on what needs to be done here and by whom?
can you guys take a look at the API quota issue?

This is happening consistently in the scale test environment
as Code Freeze is today, this needs to be of priority . Please triage! cc
It looks like the latest run on 9/1 has passed.
Marking closed as the fixes have been merged and the test runs are now passing /close
Closing this issue. <detailsIn response to : Marking closed as the fixes have been merged and the test runs are now passing /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
Change:
verifyWatchEvent(t, watcher, watch.Deleted, podFooPrime) } <del> func TestStartingResourceVersion(t *testing.T) { server, etcdStorage := newEtcdTestStorage(t, etcd3testing.PathPrefix()) defer server.Terminate(t) cacher, v, err := newTestCacher(etcdStorage) if err != nil { t.Fatalf("Couldn't create cacher: %v", err) } defer cacher.Stop() // add 1 object podFoo := makeTestPod("foo") fooCreated := updatePod(t, etcdStorage, podFoo, nil) // Set up Watch starting at fooCreated.ResourceVersion + 10 rv, err := v.ParseResourceVersion(fooCreated.ResourceVersion) if err != nil { t.Fatalf("Unexpected error: %v", err) } rv += 10 startVersion := strconv.Itoa(int(rv)) watcher, err := cacher.Watch(context.TODO(), "pods/ns/foo", storage.ListOptions{ResourceVersion: startVersion, Predicate: storage.Everything}) if err != nil { t.Fatalf("Unexpected error: %v", err) } defer watcher.Stop() lastFoo := fooCreated for i := 0; i < 11; i++ { podFooForUpdate := makeTestPod("foo") podFooForUpdate.Labels = map[string]string{"foo": strconv.Itoa(i)} lastFoo = updatePod(t, etcdStorage, podFooForUpdate, lastFoo) } select { case e := <-watcher.ResultChan(): object := e.Object if co, ok := object.(runtime.CacheableObject); ok { object = co.GetObject() } pod := object.(*example.Pod) podRV, err := v.ParseResourceVersion(pod.ResourceVersion) if err != nil { t.Fatalf("unexpected error: %v", err) } // event should have at least rv + 1, since we're starting the watch at rv if podRV <= rv { t.Errorf("expected event with resourceVersion of at least %d, got %d", rv+1, podRV) } case <-time.After(wait.ForeverTestTimeout): t.Errorf("timed out waiting for event") } } </del> func TestEmptyWatchEventCache(t *testing.T) { server, etcdStorage := newEtcdTestStorage(t, etcd3testing.PathPrefix()) defer server.Terminate(t)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Reason for failure: Anything else we need to know: /assign
/sig api-machinery /triage accepted
OK - I can quite reliably reproduce this problem by adding before this line: This seems to be a test issue (watch being closed as a result of not being able to process stuff on time). I will think how fix the test and make it not suffer from heavy cpu starvation.
Opened fix in
Change:
asw := cache.NewActualStateOfWorld(volumePluginMgr) fakeKubeClient := controllervolumetesting.CreateTestClient() ad := operationexecutor.NewOperationExecutor(fakeKubeClient, volumePluginMgr) <del> nodeInformer := informers.CreateSharedNodeIndexInformer( fakeKubeClient, resyncPeriod) nsu := statusupdater.NewNodeStatusUpdater( fakeKubeClient, nodeInformer, asw) </del> <ins> nsu := statusupdater.NewFakeNodeStatusUpdater(false /* returnError */) </ins> reconciler := NewReconciler( reconcilerLoopPeriod, maxWaitForUnmountDuration, dsw, asw, ad, nsu) podName := "pod-uid"

Discussion:
introduced logic to make kubelet volume manager wait for attach detach controller to finish attach before it starts mount. The controller should also not start a detach operation until the node status has been updated removing the volume from the list of attached volumes. Otherwise if a pod is rapidly created and deleted on the same node, it could result in a mount starting immediately before a detach starts. Props to and his pet set tests for helping catch this.
Hmm, this just happened , just a lot less frequently. Haven't debugged, but it looks like the failed pod did reland on the same node: pet-0, jenkins-e2e-minion-group-4mn2 (). Reopening, will try to confirm when i have time, and close if it's not the same thing.
Just following up with an update, Saad and i are tag teaming this. He's uploading a pr that I'm going to reivew. We're tracking a couple of issues: need to update the "volumes in use" list before polling on the "volumes attached" list. Best option is to write a operation executor, so we don't hammer the apiserver. needs to get up to date node object from apiserver to determine volumes in use. The update that removes volumes from the "attached list" shoud return a fresh node object, we can just iterate the volumes its using (this must happen after popping from attached, though). leaky volumes in the node object (this is not about the physical volumes but about the size of the json blob that's the node object growing). The proposed fix is to use the desired state of the world to update the list of volumes in use. There's a last point I need to follow up on. We might leave the node object in an inconsistent state with the proposed fix, but it should be ok since nothing is checking the inconsistent fields. This will happen if we pop a volume from the attached list, but then find its in use in the updated node object. ping me when you're ready to go, of if you need help
Change:
func (cache *schedulerCache) FilteredList(podFilter PodFilter, selector labels.Selector) ([]*v1.Pod, error) { cache.mu.Lock() defer cache.mu.Unlock() <del> var pods []*v1.Pod </del> <ins> // podFilter is expected to return true for most or all of the pods. We // can avoid expensive array growth without wasting too much memory by // pre-allocating capacity. maxSize := 0 for _, info := range cache.nodes { maxSize += len(info.pods) } pods := make([]*v1.Pod, 0, maxSize) </ins> for _, info := range cache.nodes { for _, pod := range info.pods { if podFilter(pod) && selector.Matches(labels.Set(pod.Labels)) {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --It is not a secret that . In my opinion the main reason for the slowness is the flexibility of the inter-pod affinity/anti-affinity rules. However, in most practical scenarios users do not need all the flexibility. For example, people often do not use arbitrary labels in topology key of the affinity rules. They often use node, zone, or region as the topology. Node in particular is used often. That's why I am proposing a fast path for the case that topology key is Node. Today, the affinity/anti-affinity predicate does not have any distinction for topology keys and in the cluster regardless. The logic should recognize "" and scan only pods on the same node for this topology key. Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST /kind feature /sig scheduling cc/
ref/
/assign
GitHub didn't allow me to assign the following users: misterikkit. 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
/cc
We found some other simple optimizations that had a significant impact on the affinity predicate. I will upload PRs for those as well.
Reopening this as the performance of anti-affinity still doesn't seem to be satisfactory enough on large clusters (i.e 5k nodes) - and it's causing them to fail to startup. Ref: issue I can help with evaluating any performance improvements if needed.
The change sent improved performance of the predicate, but apparently it is not enough to make our large scale scalability tests happy.
This issue is not about general performance improvment of affinity/anti-affinity. It was to implement a particular improvment which is already implemented. There are other performance improvement issues. I am going to close this one.
Sounds good. Thanks.
How come with kops 1.10.0 I still see all kube-dns pods on the same node because the kube-dns deployment doesn't specify any anti-affinity rule?
I think you are correct. you can double-check with the option to . I have a v1.9 cluster in front of me, and kube-dns has no affinity rules. (I didn't use kops though)
Change:
"template":                "Template describes the pods that will be created.", "strategy":                "The deployment strategy to use to replace existing pods with new ones.", "minReadySeconds":         "Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready)", <del> "revisionHistoryLimit":    "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 2.", </del> <ins> "revisionHistoryLimit":    "The number of old ReplicaSets to retain to allow rollback. This is a pointer to distinguish between explicit zero and not specified. Defaults to 10.", </ins> "paused":                  "Indicates that the deployment is paused.", "rollbackTo":              "The config this deployment is rolling back to. Will be cleared after rollback is done.", "progressDeadlineSeconds": "The maximum time in seconds for a deployment to make progress before it is considered to be failed. The deployment controller will continue to process failed deployments and a condition with a ProgressDeadlineExceeded reason will be surfaced in the deployment status. Once autoRollback is implemented, the deployment controller will automatically rollback failed deployments. Note that progress will not be estimated during the time a deployment is paused. Defaults to 600s.",

Discussion:
All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps
Change:
return func() (bool, error) { for i := range pods.Items { host, id, namespace := pods.Items[i].Status.Host, pods.Items[i].Name, pods.Items[i].Namespace <ins> glog.Infof("Check whether pod %s.%s exists on node %q", id, namespace, host) </ins> if len(host) == 0 { <ins> glog.Infof("Pod %s.%s is not bound to a host yet", id, namespace) </ins> return false, nil } if _, err := podInfo.GetPodStatus(host, namespace, id); err != nil {

Discussion:
A significant number of builds fail with the error If you look at , this is the leading cause of flakes (build passes on 1.4, fails on 1.3 or vice versa).
I am going to look into this one.
I kept getting emails about shippable failures... Below is the snippet of the log that includes new log messages: The host field of the pod was not assigned and the check failed after 30 seconds of polling. This means either the scheduler didn't schedule the pod or it couldn't schedule the pods due to, say, conflicts. The pod in question was from I have a wild guess. Since usually only one runtime fails (1.3 or 1.4), could it have been port conflicts (hostPort: 8080) that failed the tests?
Is this still a problem? Or can we close this issue now?
Some bugs were discovered and fixed, but in general, timeouts are still a problem in integration tests. We can close this one though because there are other issue () tracking problems like this. is currently blocked on a reflector benchmark to stress test the watch performance.
Change:
// latency for a pod. InitialAttemptTimestamp *time.Time // UnschedulablePlugins records the plugin names that the Pod failed with Unschedulable or UnschedulableAndUnresolvable status. <del> // It's registered only when the Pod is rejected in PreFilter, Filter, Reserve, or Permit (WaitOnPermit). </del> <ins> // It's registered only when the Pod is rejected in PreFilter, Filter, Reserve, PreBind or Permit (WaitOnPermit). </ins> UnschedulablePlugins sets.Set[string] // PendingPlugins records the plugin names that the Pod failed with Pending status. PendingPlugins sets.Set[string]

Discussion:
Currently, the scheduler honors Unschedulable(AndUnresolvable) or Pending only from PreFilter, Filter, Reserve, and Permit (WaitOnPermit). It doesn't expect other extension points to return those statuses and just regard all non-success status as errors, that is, immediately retrying scheduling of Pods. Actually returns Pending at PreBind, which is currently being ignored as described. So, we should expand UnschedulablePlugins/PendingPlugins to include PreBind plugins. (or maybe all extension points too?) /cc /sig scheduling /kind feature
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
Both seems reasonable to me.
Because is not handled for , the following error is logged:
This patch gets rid of the error. I am uncertain whether it has other implications? Performance was the same with and without it.
What I imagined is like that. It shouldn't have any other impact because volumebinding, which is the only PreBind plugin apart from DRA in in-tree, only returns success or error status. We have to mention the change in the release note for custom plugin developers though.
I've turned this into a PR:
Change:
node.master: ${NODE_MASTER} node.data: ${NODE_DATA} <del> transport.tcp.port: ${TRANSPORT_PORT} </del> <ins> transport.profiles.default.port: ${TRANSPORT_PORT} </ins> http.port: ${HTTP_PORT} path.data: /data network.host: 0.0.0.0 <del> discovery.zen.minimum_master_nodes: ${MINIMUM_MASTER_NODES} </del>

Discussion:
What happened: On latest fluentd-elasticsearch, the elasticsearch replicas seems failed to form a valid cluster with the service discovery helper written in golang. What you expected to happen: Successfully boot up an elasticsearch cluster I guess. How to reproduce it (as minimally and precisely as possible): Just use the yamls in and the elasticsearch-logging pods will keep spamming warning messages. I think thats because options are deprecated in elasticsearch 7.x.x Anything else we need to know?: IMHO I think thats all. Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig instrumentation
Thanks
Change:
// Apply default values and validate pods. for i := range newPods.Items { newPod := &newPods.Items[i] <ins> if newPod.Name == "" { return true, pods, fmt.Errorf("invalid pod: name is needed for the pod") } </ins> if err = defaultFn(newPod); err != nil { return true, pods, err }

Discussion:
When I put a Pod yaml file without in , started the kubelet and hoped it would create the corresponding staticPod for me, I got the following error, which also caused the staticPod to not be created. I then read the kubelet code and quickly found the problem. When kubelet tries to decode the pod yaml file, it will apply default values and validate the pod. The function to apply the defaults is in . In this function, the is set. This causes an error when is not set, because it causes the '-' character to be at the front. I think kubelet should circumvent this error, because is optional, It is possible for this field not to be set. When Pod's is not set, the '-' character at the start should be avoided, as it will cause an error. Prepare a Pod yaml file without and set it into . If the maintainers think this circumvention change is necessary, I'm happy to contribute code to the kubelet! <details</details<details</details<detailsconsole $ cat /etc/os-release NAME="Alibaba Cloud Linux" VERSION="3 (Soaring Falcon)" ID="alinux" IDLIKE="rhel fedora centos anolis" VERSIONID="3" PLATFORMID="platform:al8" PRETTYNAME="Alibaba Cloud Linux 3 (Soaring Falcon)" ANSICOLOR="0;31" HOMEURL="" $ uname -a Linux cloud 5.10.134-14.al8.x8664 SMP Thu Apr 27 16:46:29 CST 2023 x8664 x8664 x8664 GNU/Linux </details<detailsusing kubeadm </details<details</details<details</details
/sig node
I would like to open a PR to fix this issue, can I be assigned?
If the maintainer thinks this should be fixed, I want it fixed by myself:)
OK
I do not know if a pod without name should be considered valid Please discuss with sig-node before doing anything to understand what is a valid solution for this problem /cc
names are needed for the Pod. I think the correct fix for this issue will be to add validation for static Pods to have a name. This validation is OK to add since Pods without names are not working anyways because of this bug.
Okay, I will submit a PR to add validation for static Pods to have a name.

Hey, I found out that kubelet will apply default value first and then validate the pod. Do you mean to let me add a single validation for static Pods to have a name before applying default value?
hi and If modified according to this logic, it seems that the current code is fine. Current logic: it will use the old pod.Name to generate the new pod.Name , in ValidatePodCreate, it will validate pod name. The pod.Name is already to new pod.Name this case, the original pod does not have a name and will also be recognized. It's just that it's identified with a validation prefixed with "-". The logic of the current validation will recognize the pod without a name. In this way, is it necessary to improve the error information?
/triage accepted
/priority backlog
Change:
csiSource.VolumeAttributes) if err != nil { <del> glog.Errorf(log("attacher.MountDevice failed: %v", err)) if removeMountDirErr := removeMountDir(c.plugin, deviceMountPath); removeMountDirErr != nil { glog.Error(log("attacher.MountDevice failed to remove mount dir after a NodeStageVolume() error [%s]: %v", deviceMountPath, removeMountDirErr)) } </del> return err }

Discussion:
/kind bug /sig storage What happened: When using a CSI driver that does not support NODESTAGE, I can see orphan json files in that are never cleaned up. What you expected to happen: No orphan file /assign
Change:
switch originalValueTyped := originalValue.(type) { case map[string]interface{}: modifiedValueTyped := modifiedValue.(map[string]interface{}) <del> fieldType, _, _, err := forkedjson.LookupPatchMetadata(t, key) </del> <ins> fieldType, fieldPatchStrategy, _, err := forkedjson.LookupPatchMetadata(t, key) </ins> if err != nil { return nil, err } <ins> if fieldPatchStrategy == replaceDirective { if !ignoreChangesAndAdditions { patch[key] = modifiedValue } continue } </ins> patchValue, err := diffMaps(originalValueTyped, modifiedValueTyped, fieldType, ignoreChangesAndAdditions, ignoreDeletions) if err != nil { return nil, err

Discussion:
Extracted from The RawExtension type allows an API object to inline arbitrary JSON. strategicpatch.CreateTwoWayMergePatch returns an error trying to map that inlined JSON to struct fields. It should be able to compute a patch for an object containing a field of that type.
cc
We need to decide what strategic merge patch should do in the following scenarios: unknown fields (can be encountered when the API or a user-defined object has a new field the compiled-in struct doesn't have yet) unmergeable fields (like RawExtension) cc
The current behavior is: unknown fields: trying to merge a unknown field will fail when lookup the metadata in the struct tags unmergeable fields: will be replaced as raw byte array Maybe we can use generic json merge for unmergeable fields?
Did that change since 1.5? In 1.5, we were getting an error during patch computation for objects with a RawExtension field
Sorry. This behavior is in 1.4.7. e.g . It will error in 1.5.
Yeah, the field gets replaced. Even in 1.4.7, an unknown field (like initcontainers in pods) or an object including a RawExtension (anything with a field of type or ) would error
My personal favor would be to instruct the patch to ignore such field, seems the cleanest approach to me. Similarly to how we allow annotating deletion and merging.
wouldn't it be confusing to submit a patch with stuff in that field, have the patch accepted, and have none of your submitted changes take effect? seems like the least surprising thing would be to treat struct fields like or as
How about both, iow. having as a default and as an opt-in. This would allow the resource author to decide how his resource should be treated. Eventually on we could return the ignored fields. Having said that we could start with right away. I think I could work on a patch implementing that if majority agrees (
I think is a good place to start when computing/applying patches for known struct fields like RawExtension. I'll open a separate issue for client-side handling of computing patches for unknown fields
Ignore the field sounds like a really good solution. WDYT of printing a warning to stdeer?
what does ignoring instead of replacing get us?
Sorry I was reading the comment on my phone between other things. Ignore my comment.