jiebi/CodeConvo huggingface dataset:
Change:
shouldContinue = false } } <del> case <-time.After(2 * time.Second): </del> <ins> case <-time.After(wait.ForeverTestTimeout): </ins> shouldContinue = false w2.Stop() }

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: bazel-test-master (periodic-kubernetes-bazel-test-master ) Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --cc
/sig api-machinery
This is continuing to be flaky with more recent failure:
/assign Would you mind taking a look here? thanks! /triage accepted
- can we somehow uncover when this started happening? This test is very old and it seems it started happening very recently, so it would be helpful to see when this started happening...
Triage shows flakes starting ~Sept 30: Before Sept 30 it seems the job was flaking much less frequently.
Might be related to I will take a look.
It seems it's not related to that PR (neither to the previous: ) As there were already failures like that on Sep 24th (before this one was merged). I will take a deeper look.
OK - it's not related to any changes mentioned before. I can reproduce this particular failure by simply adding somewhere in this block: So it's probably connected to cpu-starvation at the test level and the solution is to switch to less aggressive timeouts. Will send out a PR.
Actually - it appeared to be slightly more subtle then that. But I already fully understand the problem. It's purely test issue, but require a bit more changes (and I won't get to it today/tomorrow). I will send a fix for that early next week.
- if that changes anything from your tracking perspective ^^
No board changes yet - the next stage is "Observing" once this issue gets closed :) If you have time - I'd love to pick your brain/understand the error more thoroughly though! Hoping you drop a good explanation in your PR next week
Thanks for sharing those insights, on your discovery of the solution to this bug.
It seems the PR didn't address that fully. Looking.
out for review
Change:
kube::etcd::cleanup() { kill "${ETCD_PID-}" >/dev/null 2>&1 || : <ins> wait "${ETCD_PID-}" >/dev/null 2>&1 || : </ins> rm -rf "${ETCD_DIR-}" }

Discussion:
Integration tests run the same test for v1beta1 and v1beta3. Sometimes second run fails complaining: This causes some flakes in travis/shippable. We should wait for the clean shutdown of the first run and only then start the second one.
Change:
ResourceVersion string `json:"resourceVersion,omitempty"` // Optional. If referring to a piece of an object instead of an entire object, this string <del> // should contain a valid field access statement. For example, // if the object reference is to a container within a pod, this would take on a value like: // "spec.containers[2]". Such statements are valid language constructs in // both go and JavaScript. This is syntax is chosen only to have some well-defined way of </del> <ins> // should contain information to identify the sub-object. For example, if the object // reference is to a container within a pod, this would take on a value like: // "spec.containers{name}" (where "name" refers to the name of the container that triggered // the event) or if no container name is specified "spec.containers[2]" (container with // index 2 in this pod). This syntax is chosen only to have some well-defined way of </ins> // referencing a part of an object. // TODO: this design is not final and this field is subject to change in the future. FieldPath string `json:"fieldPath,omitempty"`

Discussion:
Forked from ... The event generated from kubelet for BoundPod and displayed by kubectl should have Container(s) column ; otherwise, the user might think the entire pod is at the running state, but actually only one or some containers are running. When there are missing event(s) for failed containers, the thing gets worse. For example, in case, only net container is running. $ get events | grep testpd Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get events Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting created Created with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 Mon, 29 Dec 2014 20:58:38 +0000 testpd Pod Pending scheduled Successfully assigned testpd to kubernetes-minion- Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting pulled Successfully pulled image kubernetes/pause:latest Mon, 29 Dec 2014 20:58:39 +0000 testpd BoundPod running started Started with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004
Change:
invalidSeccompDefault.Annotations = map[string]string{ seccomp.DefaultProfileAnnotationKey: "not-good", } <ins> invalidSeccompAllowAnyDefault := validPSP() invalidSeccompAllowAnyDefault.Annotations = map[string]string{ seccomp.DefaultProfileAnnotationKey: "*", } </ins> invalidSeccompAllowed := validPSP() invalidSeccompAllowed.Annotations = map[string]string{ seccomp.AllowedProfilesAnnotationKey: "docker/default,not-good",

Discussion:
It should be possible to create a PodSecurityPolicy with zero restrictions. This was the intent with the (a.k.a. "AllowAny") allowed seccomp profile, but it is rejected during the validation phase. /kind bug
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/auth: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. 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
Change:
framework.ExpectNoError(err) newCfg := oldCfg.DeepCopy() updateFunction(newCfg) <ins> if reflect.DeepEqual(*newCfg, *oldCfg) { return } </ins> framework.ExpectNoError(setKubeletConfiguration(f, newCfg)) }) AfterEach(func() {

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: Run e2e node test with , and wait for new configuration take effect. But it will return new configuration has taken effect. What you expected to happen: will return with new configuration has taken effect. How to reproduce it (as minimally and precisely as possible): Run any e2e node test with . Anything else we need to know?: This is because we use period = 10 * time.Second and jitterFactor = 0.2 in . In extreme scenarios, it will take at least 12 seconds for Kubelet to catch this new config. We use this to check whether kubelet is restarted: This will return OK immediately as has been set to etcd, but kubelet don't restart with this . This function will return before new configuration has taken effect. I will send a PR to fix this. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /area kubelet /sig node /assign /cc PTAL, Thanks!
The comment that will immediately contain the new (presumably changed) config prior to a Kubelet restart is incorrect. scrapes the values from the Kubelet's /configz endpoint, which won't have updated to the new configuration until after the Kubelet has restarted.
Hi, thanks for your explanation! I add some timestamps to test this, but the result is not the some as you described. For example, returned at , but Kubelet restarted at . And after reading the code, just call this API: , and i don't find any code about waiting for Kubelet has restarted. Could you point me these code please? Thanks very much!
Are you actually changing the configuration object's values? will return the old values until the Kubelet restarts (because /configz will return the old values until the Kubelet restarts). In any case where you actually change the config values, the assertion will fail until the Kubelet restarts, and thus you'll wait for the restart before continuing past the .

Thanks, I think this is because will read on starting, the configuration is always equal to the last time changed. So getCurrentKubeletConfig() will return immediately. But I have another question here: should we double check the is not equal to the before we call in ?
returns as soon as it gets a 200 response from /configz. Nothing to do with which config the Kubelet read. If the Eventually is exiting early, it's probably because no values were changed. The Kubelet may not have even restarted yet. That's probably a useful optimization.
Yes, I agree with you. Hi, , PTAL, Thanks.
Change:
}, }, } <del> return f.ClientSet.Extensions().DaemonSets(f.Namespace.Name).Create(loader) </del> <ins> _, err := f.ClientSet.Core().ReplicationControllers(f.Namespace.Name).Create(loader) framework.ExpectNoError(err, "Failed to create apparmor-loader ReplicationController") // Wait for loader to be ready. getRunningLoaderPod(f) } func getRunningLoaderPod(f *framework.Framework) *api.Pod { label := labels.SelectorFromSet(labels.Set(map[string]string{loaderLabelKey: loaderLabelValue})) pods, err := framework.WaitForPodsWithLabelScheduled(f.ClientSet, f.Namespace.Name, label) framework.ExpectNoError(err, "Failed to schedule apparmor-loader Pod") pod := &pods.Items[0] framework.ExpectNoError(framework.WaitForPodRunningInNamespace(f.ClientSet, pod), "Failed to run apparmor-loader Pod") return pod </ins> }

Discussion:
The "AppArmor load AppArmor profiles should enforce an AppArmor profile" e2e test in failing on our 5k-node gce clusters - https://k8s- (run no. 8) due to timeout: Seems like the test is trying to load the profiles across all the nodes using a daemonset and then running a test pod to check that. It's passing on our 2k-node clusters (https://k8s-) but failing for 5k - suggesting that it's likely due to size of the cluster. I think it's the ds creation taking longer on large cluster. cc
Seems like you're the most relevant here. Could one of you take a look into it? And does increasing the timeout for the test-pod based on no. of nodes sound reasonable?
Assigning it you since is OOO. Feel free to reassign as apt.
This is part of the correctness suite and large cluster tests are release-blocking.
FYI
Reassigning to who is back on Tuesday. He wrote the AppArmor stuff and should be able to debug this quickly. /assign
Ref
Could you manage to take a look into this?
Sorry, I meant to reply to this! I have a fix, just need to confirm it works. I think you're right about the DaemonSet timing out. There's no reason this needs to load the profiles on every node, so the fix just runs a single loader, and uses pod affinity to co-schedule the test pod.
Smooth!
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/scalability: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. 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
Change:
v1.FCVolumeSource{TargetWWNs: []string{wwnLun[0]}, Lun: &lun32}) glog.V(5).Infof("ConstructBlockVolumeSpec: TargetWWNs: %v, Lun: %v", fcPV.Spec.PersistentVolumeSource.FC.TargetWWNs, <del> fcPV.Spec.PersistentVolumeSource.FC.Lun) </del> <ins> *fcPV.Spec.PersistentVolumeSource.FC.Lun) </ins> } else { fcPV = createPersistentVolumeFromFCVolumeSource(volumeName, v1.FCVolumeSource{WWIDs: []string{volumeInfo}})

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Currently, FC plugin returns volume name and empty FCVolumeSource during ConstrutVolumeSpec during . However, in order to recreate newMounter from volumeSpec, volume information are lacking. As a result, filesystem volume's reconstruction always fails. What you expected to happen: Filesystem volume's reconstruction works properly, then a volume is unmounted and detached from kubelet node. How to reproduce it (as minimally and precisely as possible): (1) Create filesystem volume using FC plugin (2) Restart kubelet service which a pod with FC volume is running Anything else we need to know?: cc Environment: Kubernetes version (use ):Install tools: local-cluster-
/assign
/sig storage
Change:
run(ctx, startSATokenController, initializersFunc) }, OnStoppedLeading: func() { <del> klog.Fatalf("leaderelection lost") </del> <ins> klog.ErrorS(nil, "leaderelection lost") klog.FlushAndExit(klog.ExitFlushTimeout, 1) </ins> }, })

Discussion:
kube-controller-manager yields whole stack trace when it loses leaderelection. kube-controller-manager to only log and to exit (without logging 17K lines of stack trace that is not useful for anyone). kube-controller-manager yields around 17K lines of stack trace (omitted in the above example). No response <detailsv1.20.12 </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/assign /triage accepted
has Fatalf always triggered a stack dump of all goroutines?
/cc
Seems like does a dump of all goroutines Could we and then maybe? /cc in case you have thoughts about this
If I read the right, it only printed the current goroutine to stderr. Dumping everything seems to have been later. make sense to me.
Dumping of all goroutines was in
I have similar doubts. I want to fix it. /assign
kube-scheduler seems to have a similar issue (but a shorter stack trace)
When replacing (useful because it doesn't do structured logging, not just because of the stack trace problem), remember to use + the new . Updated migration instructions are pending in There's also - reverting the klog change might be a faster way to address this.
Change:
LOG_FILE="${LOG_FILE:-${TMP_DIR}/update-vendor.log}" kube::log::status "logfile at ${LOG_FILE}" <ins> function finish { ret=$? if [[ ${ret} != 0 ]]; then echo "An error has occurred. Please see more details in ${LOG_FILE}" fi exit ${ret} } trap finish EXIT </ins> if [ -z "${BASH_XTRACEFD:-}" ]; then exec 19> "${LOG_FILE}" export BASH_XTRACEFD="19"

Discussion:
Seen while running on If hack/update- fails, the output should make it clear 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: /area code-organization /sig architecture /cc /assign
Maybe we can add a to check the exit code.
/cc
something like that seems like a good idea
usually when we want to do stuff like that we instead record the exit code for specific steps with something like so we can check after and inform the user of the specific failure (and suggest what to do), then
/assign
Change:
}, "time": { "$ref": "#/definitions/io.k8s.apimachinery.pkg.apis.meta.v1.Time", <del> "description": "Time is timestamp of when these fields were set. It should always be empty if Operation is 'Apply'" </del> <ins> "description": "Time is the timestamp of when the ManagedFields entry was added. The timestamp will also be updated if a field is added, the manager changes any of the owned fields value or removes a field. The timestamp does not update when a field is removed from the entry because another manager took it over." </ins> } }, "type": "object"

Discussion:
Godoc says that Time should be empty on mangedFields entry created by "Apply" operation, but kubernetes populates time on apply. Godoc consistent with kubernetes behaviour Godoc: Kubernetes: No response <details</details<details</details<details</details<details</details<details</details<details</details
/wg api-expression /sig api-machinery
/cc
/cc /triage accepted
Yeah, good catch. The comment matches the behavior from alpha, which we changed later on. Thanks for letting us now :-) I think we could do a better job describing how this value is changed now.
Change:
cmd := &cobra.Command{ Use:     "use-context CONTEXT_NAME", Short:   i18n.T("Sets the current-context in a kubeconfig file"), <ins> Aliases: []string{"use"}, </ins> Long:    `Sets the current-context in a kubeconfig file`, Example: use_context_example, Run: func(cmd *cobra.Command, args []string) {

Discussion:
The '-context' does not seem to add any value
add priority and team please.
Blocked on
/sig cli
Change:
if node != nil { zone := nodetopology.GetZoneKey(node) evictionsNumber.WithLabelValues(zone).Inc() <ins> evictionsTotal.WithLabelValues(zone).Inc() </ins> } return true, 0

Discussion:
I would like to propose the graduation of the metric from alpha to stable. The metric has been stable for 2 years now.
/sig api-machinery /sig instrumentation
I am willing to do all StabilityLevels from alpha to stable? Is that right?
/assign
- The request is to have the stability level for the metric graduate to stable. If there are other metrics you want to do at the same time that's a bonus, but not part of the request in this issue.
/sig node /remove-sig api-machinery /cc
To be promoted to stable, the metrics would need to be renamed from to in order to follow Prometheus best practices as well as sig-instrumentation naming guidelines.
/cc
/assign
/triage accepted
Change:
":(glob)${root}"/'**/zz_generated.defaults.go'  | xargs -0 rm -f <del> local inputs=() </del> <ins> local input_args=() </ins> for arg in "${input_pkgs[@]}"; do <del> inputs+=("--input-dirs" "$arg") </del> <ins> input_args+=("--input-dirs" "$arg") </ins> done "${gobin}/defaulter-gen"  -v "${v}"  -O zz_generated.defaults  --go-header-file "${boilerplate}"  --output-base "${out_base}"  <del> "${inputs[@]}" </del> <ins> "${input_args[@]}" </ins> fi # Conversions

Discussion:
Earlier it was possible to pass flag to while calling script. Now with the new script, is called under which doesnot support any other flags apart from , and . As it can be seen here there is no option to pass flag to conversion-gen Earlier in the script, it was considering all the inputs passed flag is supported by under the hood, but the function in script is not allowing the flag.
/cc
/sig api-machinery
/assign for code generation /triage accepted
/assign
Can you explain why you need this flag? What I found in k/k was that we don't actually need it at all.
You know what, my memory was faulty. We do use it (until I fix that, which is in a development branch, not merged). But we don't use it in any of the "submodule" configs.
A lot of the "magic" behind the conversion logic is very brittle. Can you help me understand where / how this impacts you?
I whipped up a quick patch but have not tested much:
We are using the flag several places in our script On removal of the flag, the autoConvert functions in. files has the error : Althoug I can see the function is already present at . But there is also a comment like Hence, I think there is a need for the in order to use this pkg.
I see. The component-base is something I didn't account for. If you apply the above patch, does the new argument to work for you?
Above patch throws an error for the cases when flag is not passed to function. Instead I followed this approach :
I'd rather not accumulate into a string - can you tell me what error it throws? Note, mine wants Also - is the argument here a dir (e.g. /home/me/src/foo/bar) or a pkg (e.g. ) ? I think it's actually a pkg, right?
You implementation throws error for the cases when we don't specify the option while calling , as shown below: For such cases I am getting following error
It seems to be an old-bash problem. Try this one?
Yes this is working fine.
OK. I'll prep a PR soon.
Thank you
Change:
if err := addPriorityClasses(ctrl, test.classesBefore); err != nil { t.Errorf("Test %q: unable to add object to informer: %v", test.name, err) } <del> defaultPriority, err := ctrl.getDefaultPriority() </del> <ins> pcName, defaultPriority, err := ctrl.getDefaultPriority() </ins> if err != nil { t.Errorf("Test %q: unexpected error while getting default priority: %v", test.name, err) } <del> if err == nil && defaultPriority != test.expectedDefaultBefore { t.Errorf("Test %q: expected default priority %d, but got %d", test.name, test.expectedDefaultBefore, defaultPriority) </del> <ins> if err == nil && (defaultPriority != test.expectedDefaultBefore || pcName != test.expectedDefaultNameBefore) { t.Errorf("Test %q: expected default priority %s(%d), but got %s(%d)", test.name, test.expectedDefaultNameBefore, test.expectedDefaultBefore, pcName, defaultPriority) </ins> } if test.attributes != nil { err := ctrl.Validate(test.attributes)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup /sig scheduling Description: If Pod did not set , admission controller will set to "default value". If the default value are from default priority class, it's better to also set of pod.
can I take this? /assign
, thanks :) I created a PR for functionality, but that'll be great if you can help add some e2e test for it. I can help to shepherd :)
thanks let me have a try :)
Change:
if forgetErr := sched.Cache().ForgetPod(assumedPod); forgetErr != nil { klog.Errorf("scheduler cache ForgetPod failed: %v", forgetErr) } <del> sched.recordSchedulingFailure(assumedPod, permitStatus.AsError(), reason, permitStatus.Message()) </del> // trigger un-reserve plugins to clean up state associated with the reserved Pod fwk.RunUnreservePlugins(pluginContext, assumedPod, scheduleResult.SuggestedHost) <ins> sched.recordSchedulingFailure(assumedPod, permitStatus.AsError(), reason, permitStatus.Message()) </ins> return }

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: TestUnreservePlugin is flaky: What you expected to happen: Test to always pass. How to reproduce it (as minimally and precisely as possible): This is a flaky test, but the issue is that the unreserve plugin didn't get the change to execute before the test checked the unreserve call counter in the test. Assuming thread1 runs the scheduler, thread2 runs the tests, here is the sequence that caused this flake: thread2 creates a pod and blocks on a . thread1 tries to schedule the pod, executing the pre-bind plugin which denies the pod and . thread2 gets unblocked before thread1 gets to . Thread2 checks the counters, throwing an error since unreserve plugin call counter didn't get to be incremented. What we need is for the test to block until unreserve is called, not until we get a scheduling error. /sig scheduling
/help
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 </details
cc/