jiebi/CodeConvo huggingface dataset:
Change:
expected: []*v1.Node{nodes[6], nodes[5], nodes[2], nodes[0]}, }, { <del> name: "Remove non-existing node", operations: []operation{ addNode(0), addNode(1), updateSnapshot(), }, expected: []*v1.Node{nodes[1], nodes[0]}, }, { </del> name: "Update some nodes", operations: []operation{ addNode(0), addNode(1), addNode(5), updateSnapshot(), updateNode(1),

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: If we delete node first, then remove pods on this node, the scheduler will crash in function What you expected to happen: Not crashed How to reproduce it (as minimally and precisely as possible): some pods on node A delete node A delete pods on node A Anything else we need to know?: Environment: Kubernetes version (use ): 1.16-1.18, even master 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 scheduling
can you show the core dump please of this crash?
/assign
I patched the unit test shown in into the , and branches. None crashed. I'll await for the crash dump.
Here is the fresh dump.
and which version was this?
This is master branch. And I've tested it from 1.16-1.18, it can be reproduced easily.
Thanks a lot. I was able to finally reproduce in unit tests. The scenario is: a node with at least 2 pods. node. pod1. In unit test, this is first an update to set the termination timestamp. No issues up to this point. pod2. Again, first an update to set the termination timestamp. Here it crashes. I'm working on a fix.
It looks like this is not an issue in 1.17 and below, because we preserved a placeholder node where the operations occur. do you have stacktraces for 1.17 and 1.16?
Yes, it seems only be found at 1.18. :smile:
Change:
sst.WaitForRunningAndReady(*ss.Spec.Replicas, ss) }) <ins> // This can't be Conformance yet because it depends on a default // StorageClass and a dynamic provisioner. It("should perform rolling updates and roll backs of template modifications with PVCs", func() { By("Creating a new StatefulSet with PVCs") *(ss.Spec.Replicas) = 3 rollbackTest(c, ns, ss) }) </ins> /* Release : v1.9 Testname: StatefulSet, Rolling Update

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: It would be good to test rolling updates with RWO PVCs that cannot be attached to multiple nodes at the same time.
There have been reports of this scenario
Change:
"k8s.io/client-go/discovery" "k8s.io/client-go/dynamic" restclient "k8s.io/client-go/rest" <ins> "k8s.io/client-go/tools/cache" </ins> "k8s.io/kubernetes/pkg/api" "k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/client/clientset_generated/clientset"

Discussion:
https://k8s- Failed: TestBlockingOwnerRefDoesBlock {garbagecollector}
cc:
https://k8s- Failed: TestBlockingOwnerRefDoesBlock {garbagecollector}
I don't have a good theory yet. It's occurring , so I'll fix the more urgent issues first.
If its that low, its not a blocker. Moving to 1.6.1
Could this be a race condition? Perhaps needs some retry logic? Note that the creation never reported an error that would be fatal to the test:
I checked the log, it appeared when GC was processing the foreground deletion of the owner RC, GC didn't find any dependents of RC. This probably is the same race we expected in no.1. To fix the test, the test can wait some seconds before sending the deletion request, so that the garbage collector will have time to update its dependency graph.
Change:
// Create a pod in one node to get evicted ginkgo.By("creating a client pod that is going to be evicted for the service " + serviceName) evictedPod := e2epod.NewAgnhostPod(namespace, "evicted-pod", nil, nil, nil) <del> evictedPod.Spec.Containers[0].Command = []string{"/bin/sh", "-c", "sleep 10; fallocate -l 10M file; sleep 10000"} </del> <ins> evictedPod.Spec.Containers[0].Command = []string{"/bin/sh", "-c", "sleep 10; dd if=/dev/zero of=file bs=1M count=10; sleep 10000"} </ins> evictedPod.Spec.Containers[0].Name = "evicted-pod" evictedPod.Spec.Containers[0].Resources = v1.ResourceRequirements{ Limits: v1.ResourceList{"ephemeral-storage": resource.MustParse("5Mi")},

Discussion:
in this test the rootfs is limited to 5M and the pod is evicted by creating a 10M file with; But this fails if the fs doesn't support the fallocate syscall. The K8s e2e must not itself require support for features that K8s does not require. I am unsure why my overlay fs in containers doesn't support fallocate(2) while the fs on the node (ext4) does. I have queried on the slack. I build my Linux kernel myself but I can't find anything related. If the command is changed to; the test works on an fs that doesn't support fallocate(2). It may seem more "primitive" but it doesn't require a feature that K8s doesn't. <detailsNone </detailsNo response No response
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 testing
Interesting /Triage accepted
Change:
// the job stabilized and won't be synced until modification or full // resync happens, we don't want to wait for the latter so we force // sync modifying it <del> job.Spec.Parallelism = &completions job, err = updateJob(f.ClientSet, f.Namespace.Name, job) </del> <ins> _, err = framework.UpdateJobWithRetries(f.ClientSet, f.Namespace.Name, job.Name, func(update *batch.Job) { update.Spec.Parallelism = &completions }) </ins> Expect(err).NotTo(HaveOccurred()) err = waitForJobFail(f.ClientSet, f.Namespace.Name, job.Name, jobTimeout) }

Discussion:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in . Previous issues for this test:
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
https://k8s- Failed: [] Job should fail a job {Kubernetes e2e suite}
Change:
if selfVersion.LTE(version) { r.isDeprecated = true } <ins> if ShouldShowHidden() { klog.Warningf("Hidden metrics have been manually overridden, showing this very deprecated metric.") return } </ins> if selfVersion.LT(version) { klog.Warningf("This metric has been deprecated for more than one release, hiding.") r.isHidden = true

Discussion:
The metrics framework requires the ability to optionally display hidden (deprecated) metrics. A boolean needs to be piped through the registry (possibly at initialization or possibly set later) which then needs to be passed to the Create function so that we can determine whether we need to actually create the metric. /sig instrumentation
Change:
return "", err } <del> if len(volumeSource.TargetWWNs) != 0 { </del> <ins> // API server validates these parameters beforehand but attach/detach // controller creates volumespec without validation. They may be nil // or zero length. We should check again to avoid unexpected conditions. if len(volumeSource.TargetWWNs) != 0 && volumeSource.Lun != nil { </ins> // TargetWWNs are the FibreChannel target worldwide names <del> return fmt.Sprintf("%v", volumeSource.TargetWWNs), nil </del> <ins> return fmt.Sprintf("%v:%v", volumeSource.TargetWWNs, *volumeSource.Lun), nil </ins> } else if len(volumeSource.WWIDs) != 0 { // WWIDs are the FibreChannel World Wide Identifiers return fmt.Sprintf("%v", volumeSource.WWIDs), nil

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: FC plugin returns TargetWWNs at GetVolumeName(), but TargetWWNs are not unique identifier if user has multiple volumes from same target wwn. As a result, after introducing attach/detach functions, FC plugin always fails to attach volumes if a pod requests 2+ luns. The GetVolumeName() is called from GetUniqueVolumeNameFromSpec() during Pod creation. FC plugin should return unique identifier in the GetVolumeName(). If user uses WWID to specify FC volume, this problem doesn't happen because the WWID is unique identifier. What you expected to happen: All FC volumes are attached to pod. How to reproduce it (as minimally and precisely as possible): Create two PVs and PVCs which uses same target wwn. Create Pod with these two PVCs Anything else we need to know?: Environment: Kubernetes version (use ):Install tools: local-up- /cc
/sig storage
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Change:
import ( "fmt" "net" <ins> "runtime" </ins> "strconv" "strings"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When running , and passing the flag which was introduced in , the following error occurs: What you expected to happen: The proxy should work as it used to, supporting this mode. How to reproduce it (as minimally and precisely as possible): ./kube- --proxy-mode=kernelspace Anything else we need to know?: This was introduced after the validation was refactored in which regressed validation for . IPVS validation (and thus support) was later , but we need another mode for Windows. Environment: Kubernetes version (use ): v1.10.0-alpha.0.684+ Cloud provider or hardware configuration: n/a OS (e.g. from ): Windows Server Core 1709 Kernel (e.g. ): Install tools: Others:
/sig windows /sig network
Tentatively adding milestone so we can track getting consensus on release-blocking status.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : 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
Change:
return fmt.Errorf("failed os init: %w", err) } <del> if err := opts.Complete(); err != nil { </del> <ins> if err := opts.Complete(cmd.Flags()); err != nil { </ins> return fmt.Errorf("failed complete: %w", err) }

Discussion:
introduced configuration of additional logging aspects (e.g. format) through command line flags and config file. This was merged for Kubernetes 1.28. Now the following invocation doesn't work as expected when the config file doesn't configure logging: It should run with verbosity 4. Instead it runs with verbosity 0, from the config. Run with this config file: No response 28 rc n/a No response No response No response No response
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 problem is caused by this line: At that point, is 4 (from the command line flag), and then it gets overwritten with == 0. The normal approach would be: set up config with defaults modify config through flags modify config further by parsing a config file into it. Can kube-proxy do this? It has the downside that a config file can only overwrite fields if they are in the file. A config field doesn't get reset to defaults just by parsing the file. /cc
it looks like kube-proxy special-cases the to let a flag override config... can/should it do the same thing for verbosity? are there any other flags like this?
I don't think that's the normal approach... it's more normal to make flags and config file mutually exclusive. That's difficult for things which started as flags and moved into config
/sig network /sig instrumentation /kind bug /kind regression /milestone v1.28
let's go with and warn it and comment as much as possible, I was going with something like but Patrick is working on it so I assign to him the issue
/assign
Hey folks, v1.28 Bug Triage Lead here Just wanted to know if this is already tracked by SIG leads and someone already working actively fixing it and set a priority?
Perhaps I should have said "this is how component-base/logs was meant to be used". Somehow it worked for kubelet.

Here's my preliminary solution: It needs more testing, but I wanted to share it early because I am running out of time today.
it is , I can take over Patrick's work in case is needed
It would be nice if the logs API could distinguish between and , how about make to a pointer? But this change is supposed to be a breaking change, I'm not sure of the scope of the impact. For side, if set and at the same time, should the command flag override the config file or warn it and be discarded? I think it should be overridden.
xref:
Change:
cmdArgs = append(cmdArgs, "--runtime-cgroups=/docker-daemon", "--kubelet-cgroups=/kubelet", <ins> "--cgroup-root=/", "--system-cgroups=/system", </ins> ) } cmdArgs = append(cmdArgs,

Discussion:
In node-e2e-test on Containervm image, the containers of the pods created by Kubernetes are subcontainers of docker-daemon/docker/. It means that the runtime resource usage (docker-daemon) is not correct, because all pods are included. This problem maybe due to container misconfiguration in node-e2e-test.
The kubelet on debian-based containervm image is misconfigured. Will fix it shortly.
Change:
finalAttached:        false, finalAttachErr:       &storage.VolumeError{Message: "missing volume"}, trigerWatchEventTime: 5 * time.Millisecond, <del> sleepTime:            10 * time.Millisecond, </del> timeout:              30 * time.Millisecond, shouldFail:           true, },

Discussion:
/kind bug /sig storage What happened: CSI unit tests occasionally end up with data race: How to reproduce it (as minimally and precisely as possible): to get CSI unit tests into a binary: the binary 500 times in parallel until it breaks: . Use different argument to really load your machine, it should not be idle! . On my Linux, I got 3 failures in ~1000 runs. puts stderr of failed runs into .
/assign
I make a Fix: PTAL
Change:
HardPodAffinitySymmetricWeight: 1, HealthzBindAddress:             "0.0.0.0:10251", MetricsBindAddress:             "0.0.0.0:10251", <ins> DebuggingConfiguration: componentbaseconfig.DebuggingConfiguration{ EnableProfiling:           true, EnableContentionProfiling: true, }, </ins> LeaderElection: kubeschedulerconfig.KubeSchedulerLeaderElectionConfiguration{ LeaderElectionConfiguration: componentbaseconfig.LeaderElectionConfiguration{ LeaderElect:       false,

Discussion:
What would you like to be : Enable profiling by default in the scheduler. We can do this by defaulting the CC flags to true. Why is this needed: It is useful when debugging the performance of a running cluster. API server already enables profiling by default. /sig scheduling /help /milestone v1.17
/assign /remove-help
Change:
**Note**: You will want to set the Docker VM to have at least 8GB of initial memory or building will likely fail. (See: [#11852]( http://issue.k8s.io/11852)). * **Linux with local Docker**  Install Docker according to the [instructions](https://docs.docker.com/installation/#installation) for your OS. * **Windows with Docker Desktop WSL2 backend**  Install Docker according to the [instructions](https://docs.docker.com/docker-for-windows/wsl-tech-preview/). Be sure to store your sources in the local Linux file system, not the Windows remote mount at `/mnt/c`. <del> **Note**: You will need to check if Docker CLI plugin buildx is properly installed. You can install buildx according to the [instructions](https://github.com/docker/buildx/blob/master/README.md#installing). </del> <ins> **Note**: You will need to check if Docker CLI plugin buildx is properly installed (`docker-buildx` file should be present in `~/.docker/cli-plugins`). You can install buildx according to the [instructions](https://github.com/docker/buildx/blob/master/README.md#installing). </ins> 2. **Optional** [Google Cloud SDK](https://developers.google.com/cloud/sdk/) You must install and configure Google Cloud SDK if you want to upload your release to Google Cloud Storage and may safely omit this otherwise.

Discussion:
does not explicitly mention that buildx cli plugin is required for this operation. If buildx is not present, running gives the following error (which is not very helpful.) Running the manual command also results in the same error. I think that the doc should mention that buildx cli plugin should be present for the Docker Image to successfully build, how users can check if buildx is installed, and if not already present. (I'm very new to kubernetes community, and I spent 2-3 days trying to figure this out, so this could really help beginners who get stuck here).
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 contributor-experience
/kind documentation
this seems like a valid improvement. if someone wants to take this, PRs are welcome. EDIT: it seems the buildx cli plugin installation is a bit vague on the side of docker too. thus i will not add the label.
Happy to help here Docker Buildx installation can be verified by checking if file is present in . Buildx can be installed by the following sequence of commands (): Also, should this issue be left open for community (such as first time contributors) or should I make the changes and raise a PR (if we need it quickly)?
if you think you can make the change, please go ahead. thanks
Change:
State:  status.WorkType(), Orphan: orphan, } <del> if status.activeUpdate != nil && status.activeUpdate.Pod != nil { sync.HasConfig = true sync.Static = kubetypes.IsStaticPod(status.activeUpdate.Pod) </del> <ins> switch { case status.activeUpdate != nil: if status.activeUpdate.Pod != nil { sync.HasConfig = true sync.Static = kubetypes.IsStaticPod(status.activeUpdate.Pod) } case status.pendingUpdate != nil: if status.pendingUpdate.Pod != nil { sync.HasConfig = true sync.Static = kubetypes.IsStaticPod(status.pendingUpdate.Pod) } </ins> } workers[uid] = sync }

Discussion:
The following log line is often (~30times) logged during our tests in : . This suggests a possible bug as it was assumed to do not happen. No log line saying . Look at artifacts of all (or almost all) builds of: No response <details</details<detailsReproducible in tests </details<details</details<details</details<details</details<details</details
/sig node FYI
/triage accepted since it's a new error, it is a regression. So adding a corresponding priority /priority important-soon
are you working on this? Should I assign bug to you?
Yes, I'm taking a look at this. /assign
/cc
This is a metrics only error (we don’t report a fraction of metrics) and has no functional impact.
That makes sense, but is it expected that this is a valid state in first place? . My assumption was that if static is false, (i.e. API pod) then we should have a config?
I took a closer look at the logs, it seems that this is happening when we enter while a static pod is being synced which has UID reuse and another pod which has the same full name did not terminate yet. In this case, we block the static pod from starting i.e. () returns false: Because the pod can't start, we don't set : which means that when we log metrics there is no set and thus or are both defaulted to false:
Based on the above, it looks like this case is expected. As a result, maybe the simplest option is to simply drop the log statement since by design we only want to into account a subset of the states for the metrics?
Change:
func (a *azureDriver) CreateVolume(config *testsuites.PerTestConfig, volType testpatterns.TestVolType) testsuites.TestVolume { ginkgo.By("creating a test azure disk volume") <ins> if volType == testpatterns.InlineVolume { // Volume will be created in framework.TestContext.CloudConfig.Zone zone, // so pods should be also scheduled there. config.ClientNodeSelector = map[string]string{ v1.LabelZoneFailureDomain: framework.TestContext.CloudConfig.Zone, } } </ins> volumeName, err := framework.CreatePDWithRetry() framework.ExpectNoError(err) return &azureVolume{

Discussion:
I am trying to run Azure e2e tests: The test creates a volume in the cloud + runs a pod with the volume as in-line. The pod never starts: The test creates a "blob" disk, while the Azure machine expects "managed" disk. Does anyone run storage e2e tests on Azure regularly? Was it ever working? Managed disks are provisioned . Should the test suite create "managed" disks by default too? Environment: Kubernetes version (use ): v1.17.0-alpha.0.1089+-dirty
/sig azure
/sig cloud-provider
managed disk should be the default, the azure disk storage class in the test case may have
The volume is created outside of kubernetes dynamic provisioning to test pre-provisioned and inline volumes: I wonder if anyone actually runs the tests.