jiebi/CodeConvo huggingface dataset:
Change:
informerFactory.Extensions().V1beta1().DaemonSets().Informer().GetStore(), informerFactory.Core().V1().Pods().Informer().GetStore(), informerFactory.Core().V1().Nodes().Informer().GetStore(), <ins> fakeRecorder, </ins> }, podControl, clientset }

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): DaemonSet FailedPlacement Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): OL7.3 Kernel (e.g. ): 4.1.12-94.2.1.el7uek.x86_64 Install tools: Others: What happened: I have a DaemonSet that is only deployed to a subset of nodes in the cluster based on a . I'm seeing events fired with reason for the daemonset pods on nodes that do not fit the selector. What you expected to happen: These events should never fire because they do not meet the node selectors in the pod spec. How to reproduce it (as minimally and precisely as possible): Create a cluster with different sized nodes. E.g. smaller masters than workers. Then deploy the daemonset only to the workers. You will see events triggered for the master nodes that don't meet the requirements. Anything else we need to know:
DaemonSet controller will run predicates to check if node should run daemon pod. In the progress of predicates, it will check if pod fits resources first before other predicates such as PodSelectorMatches. /cc
I think this bug appeared when critical pods were introduced and order of checking predicates changed. The event is useless for daemonsets in current situation :/ I'm not sure if there is a clean way to fix it.
I feel like a clean solution would be to look at the predicate reasons twice. The first time you look at the reasons and keep track if any are not intentional. If all of the reasons are intentional then skip checking the reasons.
actually just changing the order of checks in GeneralPredicates may just work. I'm testing the fix now.
Ok, GeneralPredicates returns all reasons. Error that pod doesn't match the node is also returned but because it's "intentional" there is no event for it.

The event "Node didn't have enough resource" should be sent only when there are no other "intentional" reasons.
Yes, I think maybe we need to check reason list twice: check is in tail of predicate list.
/cc
any PR for this? If not, I can help
I will have some time to work on it next week. If you have a spare time you can create a PR.
/assign
Change:
// This is the sleep interval specified in the command executed in the pod so that container is restarted within the expected test run time sleepIntervalWithRestart string = "60s" <ins> // This is the sleep interval specified in the command executed in the pod so that container is restarted within the expected test run time sleepIntervalToCompletion string = "5s" </ins> ) func testDevicePlugin(f *framework.Framework, pluginSockDir string) { pluginSockDir = filepath.Join(pluginSockDir) + "/" <ins> type ResourceValue struct { Allocatable int Capacity    int } devicePluginGracefulTimeout := 5 * time.Minute // see endpointStopGracePeriod in pkg/kubelet/cm/devicemanager/types.go var getNodeResourceValues = func(ctx context.Context, resourceName string) ResourceValue { ginkgo.GinkgoHelper() node := getLocalNode(ctx, f) // -1 represents that the resource is not found result := ResourceValue{ Allocatable: -1, Capacity:    -1, } for key, val := range node.Status.Capacity { resource := string(key) if resource == resourceName { result.Capacity = int(val.Value()) break } } for key, val := range node.Status.Allocatable { resource := string(key) if resource == resourceName { result.Allocatable = int(val.Value()) break } } return result } </ins> f.Context("DevicePlugin", f.WithSerial(), f.WithDisruptive(), func() { var devicePluginPod, dptemplate *v1.Pod var v1alphaPodResources *kubeletpodresourcesv1alpha1.ListPodResourcesResponse

Discussion:
Pods that already succeeded and waiting for finalizer are being readmitted, fail to be admitted and moving from Succeeded Phase to Failed (admission failed) phase. The correct behavior would be to not try to re-admit the succeeded (or failed) Pod. Specific case: Node is exposing Devices using device plugin. Device plugin is implemented as a Pod Job's pod that is using the Device run to completion and waiting for Job Status finalizer kubelet is being restarted DevicePlugin pod is reconnecting to the kubelet. While it is reconnecting, kubelet don't have availability of devices kubelet re-admits the Pod, even though it is terminated already kubelet marks the pod as "failed to be admitted" But the same can happen with the variations of GC speed and other admission handlers. /sig node /priority important-soon /cc There is also a wider issue: , that concentrates on running pods. This issue is about terminated Pods, which is less controversial. <detailsFor sure on master, may be on earlier versions. </details<detailsN/A </details<detailsN/A </details<detailsN/A </details<detailsN/A </details<detailsN/A </details
/triage accepted I think we have at least another issue mentioning the same behavior but observed for jobs, I'll look it up and crosslink later
Change:
// klog.V(4).Infof("rbd: info %s using mon %s, pool %s id %s key %s", b.Image, mon, b.Pool, id, secret) output, err = b.exec.Command("rbd", <del> "info", b.Image, "--pool", b.Pool, "-m", mon, "--id", id, "--key="+secret, "-k=/dev/null", "--format=json").CombinedOutput() </del> <ins> "info", b.Image, "--pool", b.Pool, "-m", mon, "--id", id, "--key="+secret, "-k=/dev/null", "--format=json").Output() </ins> if err, ok := err.(*exec.Error); ok { if err.Err == exec.ErrNotFound {

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: When I use intree-rbd to expand a pvc from 20Gi to 30Gi, it has been in the Resizing state for a long time. And kube-controller-manager reported this error The most important msg is: I found this err: After I read this part of the code, I realized that the output of command "rbd info" is not a struct. What you expected to happen: Pvc expand successful.
/sig storage
/assign
can you please let me know whats the ceph cluster version being used in your setup ? I am working on the fix.
I totally forgot this...
by any chance you have a nautilus cluster or any plans to migrate? if thats the case I can directly check on nautilus.
I don't have a nautilus cluster,but I think you can check on nautilus. By the way, I have fix this in But I forgot to fix and add some testcase in .
isn't the problem simply the use of in that includes the stderr line of rbd info (which starts with -1) which is not json, the json is only on stdout
How about the following change ?
if the only stderr line being parsed on your cluster is you can work around that by providing the controller-manager an empty
If you have time to make a PR for this bug, please just do it. I'm too busy these days, and my network is so poor that I can't even clone the code. Thanks a lot.
Change:
openAPIV3Config:            c.GenericConfig.OpenAPIV3Config, proxyCurrentCertKeyContent: func() (bytes []byte, bytes2 []byte) { return nil, nil }, rejectForwardingRedirects:  c.ExtraConfig.RejectForwardingRedirects, <ins> tracerProvider:             c.GenericConfig.TracerProvider, </ins> } // used later  to filter the served resource by those that have expired.

Discussion:
Extension API servers do not currently receive the header when requests are proxied through kube-aggregator, so spans are not linked properly. Traces from the extension API sever should be linked to the parent in kube-aggregator. tracing for kube-apiserver tracing for sample-apiserver and aggregate it to kube-apiserver a request to kube-apiserver for one of the resources from sample-apiserver sample-apiserver traces will not be linked to the kube-apiserver traces No response <detailsThis problem currently exists on . </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
Change:
"//pkg/volume:go_default_library", "//pkg/volume/testing:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/client-go/util/testing:go_default_library", "//staging/src/k8s.io/cloud-provider:go_default_library",

Discussion:
FEATURE REQUEST: vSphere volume plugin does not support volume device yet. Need to add volumeMode in PV spec as other plugin did. release 1.12
/sig storage
Change:
{ Name:    name, Image:   image, <del> Command: []string{"/node-problem-detector", "--logtostderr", "--system-log-monitors=" + configFile, fmt.Sprintf("--apiserver-override=%s?inClusterConfig=false", framework.TestContext.Host)}, </del> <ins> Command: []string{"sh", "-c", "touch " + logFile + " && /node-problem-detector --logtostderr --system-log-monitors=" + configFile + fmt.Sprintf(" --apiserver-override=%s?inClusterConfig=false", framework.TestContext.Host)}, </ins> Env: []v1.EnvVar{ { Name: "NODE_NAME",

Discussion:
Leads to this avc: In general, HostPath volumes in tests are bad news for selinux.
Change:
logger := &respLogger{ startTime:         startTime, req:               req, <ins> userAgent:         req.UserAgent(), </ins> w:                 w, logStacktracePred: DefaultStacktracePred, }

Discussion:
Apiserver crashed with stacktrace: Not to crash I was able to reproduce it by "slowing down" deleting headers in Authentication filter (): And making requests (around 5-10 requests to trigger this race condition): Crash was caused by race condition - one goroutine was modifying headers of requests (for example authentication filter). The other goroutine was trying to get UserAgent from request, which is also taken from request's headers map. This causes unrecoverable panic. <detailsAll versions, tested on 1.21 </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /priority important-soon
/triage accepted
Reopening - since we need to cherrypick it to previous releasses.
- friendly ping on opening cherrypicks
I've opened two cherry-picks:
One more for 1.20:
All merged - thanks!
Change:
} }) <del> ginkgo.It("should patch a pod status", func() { </del> <ins> /* Release: v1.25 Testname: Pods, patching status Description: A pod is created which MUST succeed and be found running. The pod status when patched MUST succeed. Given the patching of the pod status, the fields MUST equal the new values. */ framework.ConformanceIt("should patch a pod status", func() { </ins> ns := f.Namespace.Name podClient := f.ClientSet.CoreV1().Pods(ns) podName := "pod-" + utilrand.String(5)

Discussion:
[X] test approval issue : [X] test pr : 28/07/2022 [X] two weeks soak end date : 12/07/2022 [X] test promotion pr : The endpoint as seen on the website is tested but not part of conformance. The APIsnoop query below shows that there is no conformance test for this endpoint. patchCoreV1NamespacedPodStatus Using a number of existing e2e test practices a new has been created for this pod status endpoint. The e2e logs for this test are listed below. This query shows the pod status endpoints hit within a short period of running the e2e test. If a test with these calls gets merged, test coverage will go up by 1 point. This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance /sig node
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale targeting this for 1.25
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
"STANDARD_D5_V2_PROMO":   64, "STANDARD_D64AS_V4":      32, "STANDARD_D64A_V4":       32, <ins> "STANDARD_D64DS_V4":      32, "STANDARD_D64D_V4":       32, </ins> "STANDARD_D64S_V3":       32, "STANDARD_D64_V3":        32, "STANDARD_D8AS_V4":       16, "STANDARD_D8A_V4":        16, <ins> "STANDARD_D8DS_V4":       16, "STANDARD_D8D_V4":        16, </ins> "STANDARD_D8S_V3":        16, "STANDARD_D8_V3":         16, "STANDARD_D96AS_V4":      32,

Discussion:
<!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily:
Change:
-o -wholename './target'  -o -wholename '*/third_party/*'  -o -wholename '*/Godeps/*'  <del> -o -wholename '*/contrib/podex/*'  </del> <ins> -o -wholename '*/contrib/podex/*'  </ins> ) -prune  ) -name '*_test.go' -print0 | xargs -0n1 dirname | sed 's|^./||' | sort -u ) } <del> kube::test::find_pkgs() { kube::test::find_dirs | xargs -n1 printf "${KUBE_GO_PACKAGE}/%sn" } </del> # -covermode=atomic becomes default with -race in Go >=1.3 KUBE_TIMEOUT=${KUBE_TIMEOUT:--timeout 120s} <del> KUBE_COVER=${KUBE_COVER:-} # use KUBE_COVER="-cover -covermode=atomic" for full coverage </del> <ins> KUBE_COVER=${KUBE_COVER:-n} # set to 'y' to enable coverage collection KUBE_COVERMODE=${KUBE_COVERMODE:-atomic} # How many 'go test' instances to run simultaneously when running tests in # coverage mode. KUBE_COVERPROCS=${KUBE_COVERPROCS:-4} </ins> KUBE_RACE=${KUBE_RACE:-}   # use KUBE_RACE="-race" to enable race testing <ins> # Set to the goveralls binary path to report coverage results to Coveralls.io. KUBE_GOVERALLS_BIN=${KUBE_GOVERALLS_BIN:-} </ins> kube::test::usage() { kube::log::usage_from_stdin <<EOF

Discussion:
Our test- script invokes 'go test' serially for each pkg - currently taking 2 minutes on my laptop. Running a single 'go test' for all pkgs cuts the time down to 45 seconds. Even running with -race is only 1:15. As far as I can tell, the only time we HAVE to run serially is when coverage is on. Does anyone have time to fix this?
I'd created on Friday to fix this, though it's not yet been reviewed.
I cobbled together but I'll review yours since it is probably better :) , Jeff Grafton wrote:
Change:
"fmt" "reflect" "strings" <del> "sync" </del> "testing" "time"

Discussion:
pull-kubernetes-unit TestController2updateCronJob/spec.schedulechanged TestController2_updateCronJob /sig apps /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This is important to resolve before promotion to v1
looks like the cause was
This function should be related.
Another one:
When the flake happen, there are messages like When the system is overloaded, it would happen. is trying to replace the current queue in tests with a mock.
Yeah, I spoke with to make sure we use a mock of the queue so we only get the most important bit of information ignoring the remaining parts
Change:
) > "${KUBE_TEMP}/minion-start-${i}.sh" local scopes_flag="${scope_flags[@]}" <del> create-instance "${MINION_NAMES[$i]}" "${scopes_flag}" "startup-script=${KUBE_TEMP}/minion-start-${i}.sh" & </del> <ins> create-minion "${MINION_NAMES[$i]}" "${scopes_flag}" "startup-script=${KUBE_TEMP}/minion-start-${i}.sh" & </ins> if [ $i -ne 0 ] && [ $((i%5)) -eq 0 ]; then echo Waiting for creation of a batch of instances at $i...

Discussion:
The node disk type should be an option in the cluster/gce/config-*.sh files. The nodes get created here:
And also the disk size.
How to do this for aws ? I am stuck at 10GB minion
It . A pull request adding it would be very welcome!
please check this thread
Hello there, can I do something to make this available in the command ? I'd like to us an SSD drive :)
Change:
// Deleted if the older Deleted's object is a // DeletedFinalStateUnknown. // <del> // The other difference is that DeltaFIFO has an additional way that // an object can be applied to an accumulator, called Sync. </del> <ins> // The other difference is that DeltaFIFO has two additional ways that // an object can be applied to an accumulator: Replaced and Sync. // If EmitDeltaTypeReplaced is not set to true, Sync will be used in // replace events for backwards compatibility.  Sync is used for periodic // resync events. </ins> // // DeltaFIFO is a producer-consumer queue, where a Reflector is // intended to be the producer, and the consumer is whatever calls

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: While reviewing for I noticed that introduced a second type of Delta that is specific to DeltaFIFO but did not update the relevant documentation at , which was introduced by concurrent PR . What you expected to happen: I expected the documentation on DeltaFIFO to be current. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 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:
BTW, I think it would be more reader-friendly if the definitions of Deltas and related types were closer to their mentions near the top of the file rather than near the end.
/help /triage accepted
This request has been marked as needing help from a contributor. 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 : /help /triage accepted </details
Hi, is someone working on this? If no, can I pick it up? Thanks.
: go ahead, and thanks!
Thanks! /assign
Change:
clientset "k8s.io/client-go/kubernetes" "k8s.io/client-go/rest" v1 "k8s.io/client-go/tools/clientcmd/api/v1" <ins> resttransport "k8s.io/client-go/transport" </ins> kubeapiservertesting "k8s.io/kubernetes/cmd/kube-apiserver/app/testing" "k8s.io/kubernetes/pkg/apis/autoscaling" api "k8s.io/kubernetes/pkg/apis/core"

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/kind flake <!-- Please assign a SIG using: /sig SIG-NAME --/sig api-machinery
/assign I want to take a try
2 but actual 0 till timeout resource services, expected 2, actual 0 error waiting or ResourceQuota status: timed out waiting for the condition time later, actual state became 2 Seems polls a ResourceQuota status with timeout 10s may be not enough, we should enlarge it into 300s, that is poll for 300s timeout instead of 10s.
/triage accepted
Change:
Consistently(func() error { return verifyNoEvents(c.Events(eventNamespace), eventListOptions) }, pollConsistent, pollInterval).Should(Succeed()) <del> By("Make sure the default node condition is false") Consistently(func() error { </del> <ins> By("Make sure the default node condition is generated") Eventually(func() error { </ins> return verifyCondition(c.Nodes(), node.Name, condition, api.ConditionFalse, defaultReason, defaultMessage) }, pollConsistent, pollInterval).Should(Succeed())

Discussion:
https://k8s- Failed: [] Pods should have their auto-restart back-off timer reset on image update [Slow] {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Pods should have their auto-restart back-off timer reset on image update [Slow] {Kubernetes e2e suite}
https://k8s- Failed: [] Pods should have their auto-restart back-off timer reset on image update [Slow] {Kubernetes e2e suite}
https://k8s- Failed: [] Pods should have their auto-restart back-off timer reset on image update [Slow] {Kubernetes e2e suite}
https://k8s- Failed: [] Pods should have their auto-restart back-off timer reset on image update [Slow] {Kubernetes e2e suite}

https://k8s- Failed: [] NodeProblemDetector [] KernelMonitor should generate node condition and events for corresponding errors {Kubernetes e2e suite}
Change:
return false } <del> // probeGracePeriodInUse returns true if the pod spec is non-nil and has a probe that makes use // of the probe-level terminationGracePeriodSeconds feature func probeGracePeriodInUse(podSpec *api.PodSpec) bool { if podSpec == nil { return false } var inUse bool VisitContainers(podSpec, AllContainers, func(c *api.Container, containerType ContainerType) bool { // cannot be set for readiness probes if (c.LivenessProbe != nil && c.LivenessProbe.TerminationGracePeriodSeconds != nil) || (c.StartupProbe != nil && c.StartupProbe.TerminationGracePeriodSeconds != nil) { inUse = true return false } return true }) return inUse } </del> // schedulingGatesInUse returns true if the pod spec is non-nil and it has SchedulingGates field set. func schedulingGatesInUse(podSpec *api.PodSpec) bool { if podSpec == nil {

Discussion:
Kubernetes does not respect the of a probe. I found this while fixing the e2e tests. Test result: /kind regression /kind bug /sig node /priority important-soon The of a container's probe should override the pod's . a pod with long pod-level terminationGracePeriodSeconds and short probe-level terminationGracePeriodSeconds. for the container not respecting the probe-level terminationGracePeriodSeconds 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
I guess the probe's terminationGracePeriodSeconds field is dropped for some reason.
/assign