jiebi/CodeConvo huggingface dataset:
Change:
less, err := isLess(iField, jField) if err != nil { <del> klog.Fatalf("Field %s in %T is an unsortable type: %s, err: %v", r.field, iObj, iField.Kind().String(), err) </del> <ins> klog.Exitf("Field %s in %T is an unsortable type: %s, err: %v", r.field, iObj, iField.Kind().String(), err) </ins> } return less }

Discussion:
I am getting a crash when trying to sort pod with kubectl on Not crashing and at least an error message <details<summaryCrash log</summary</details- Kubernetes version (use ): Cloud provider or hardware configuration: tried on kind latest and openshift 4.7 OS (e.g: ): debian sid Kernel (e.g. ): 5.11.x Install tools: NA Network plugin and version (if this is a network-related bug): NA Others: kubectl compiled from tip branch (as of this bug report) with GO version 1.16.5
/sig cli
Hey I'm not able to reproduce the crash, although I do get an error on running However, the following works: Could you try this and check if this crashes as well?
It definitively crashes it, did you test it in a repo where there is actual pod in there? that error would not show if there is nothing.
Yep Hmm, interesting. Will try to reproduce it again
Sorry, not sure how to remove the label but this is expected. When sorting if the type is not expected it will output errors using over which will logs to the FATAL, ERROR, WARNING, and INFO logs, including a stack trace of all running goroutines, then calls os.Exit(255). Arguments are handled in the manner of fmt.Printf; a newline is appended if missing.
Those labels are not set on the issue: <detailsIn response to : /remove-kind bug 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
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
You need to have multiple pods to reproduce this error. It won't happen with just one pod. For example: The error says the type can't be sorted, so that is the problem: As said, this error is generated intentionally.

Here is the code: The problem stems from the fact that  has no way to return an error, so it logs a fatal error which os.Exits. It seems like the problem is that the error message is too verbose. One solution could be to change the code to only print the error message and exit, instead of using which is what is outputting the stack trace. It probably doesn't make sense to dump a stack trace for something that is a user error.
Change:
- apiGroups: - "" resources: <ins> - pods/finalizers verbs: - update - apiGroups: - "" resources: </ins> - persistentvolumeclaims verbs: - create

Discussion:
This test fails when OwnerReferencesPermissionEnforcement admission plugin is enabled: After the test creates a pod with an ephemeral volume, ephemeral volume controller in kube-controller-manager fails to create a PVC for it: The controller must have permissions to to be allowed to set with to Pods. The test passes. With : ENABLEADMISSIONPLUGINS="NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,Priority,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,OwnerReferencesPermissionEnforcement" ALLOWPRIVILEGED=true LOGLEVEL=4 hack/local-up- Kubernetes version (use ): 1.21.0 & today's master
/sig storage /triage accepted /priority important-soon
Change:
} } <ins> func TestVersionCheck(t *testing.T) { f := NewTestFieldManager(t) obj := &corev1.Pod{} // patch has 'apiVersion: apps/v1' and live version is apps/v1 -> no errors _, err := f.Apply(obj, []byte(`{ "apiVersion": "apps/v1", "kind": "Deployment", }`), "fieldmanager_test", false) if err != nil { t.Fatalf("failed to apply object: %v", err) } // patch has 'apiVersion: apps/v2' but live version is apps/v1 -> error _, err = f.Apply(obj, []byte(`{ "apiVersion": "apps/v2", "kind": "Deployment", }`), "fieldmanager_test", false) if err == nil { t.Fatalf("expected an error from mismatched patch and live versions") } switch typ := err.(type) { default: t.Fatalf("expected error to be of type %T was %T", apierrors.StatusError{}, typ) case apierrors.APIStatus: if typ.Status().Code != http.StatusBadRequest { t.Fatalf("expected status code to be %d but was %d", http.StatusBadRequest, typ.Status().Code) } } } </ins> func TestApplyDoesNotStripLabels(t *testing.T) { f := NewTestFieldManager(t) obj := &corev1.Pod{} newObj, err := f.Apply(obj, []byte(`{ <del> "apiVersion": "v1", </del> <ins> "apiVersion": "apps/v1", </ins> "kind": "Pod", "metadata": { "labels": {

Discussion:
What happened: When sending a request to the server side apply endpoint (), if the apiVersion provided in the object is different from the apiVersion in the url, it returns a 500 error, like: What you expected to happen: The request should fail if the apiVersion provided in the object is different from the apiVersion in the url, but it should fail before trying to merge, and be a 4xx error. Probably a bad request error. Anything else we need to know?: The check should probably be done somewhere near this . The issue, though, is that the patch is given as a byte array, and needs to be deserialized into an object to access the apiVersion field. How to reproduce it (as minimally and precisely as possible): With a kube-apiserver built from head, running with :
/kind bug /sig api-machinery /wg apply /priority important-longterm /assign
Change:
trigger scaling up and down the number of pods in your application. * <strong>New GUI</strong> (dashboard) allows you to get started quickly and enables the same functionality found in the CLI as a more approachable and discoverable way of <del> interacting with the system. Note: the GUI is eanbled by default for new cluster creation, however, it does not </del> <ins> interacting with the system. Note: the GUI is enabled by default in 1.2 clusters. </ins> <del> <img src="docs/images/newgui.png" width="" alt="XXX image" title="XXX image tooltip"> </del> <ins> <img src="docs/images/newgui.png" width="" alt="Dashboard UI screenshot showing cards that represent applications that run inside a cluster" title="Dashboard UI apps screen"> </ins> ## Other notable improvements

Discussion:
The says this about the new GUI: It does not what? Seems important!
Hmm... That's interesting. Will fix.
Change:
{Type: "third"}, }, }, <ins> { name:          "empty_conditions", conditions:    []metav1.Condition{}, conditionType: "Foo", expected:      []metav1.Condition{}, }, </ins> } for _, test := range tests {

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 --Attempting to remove a status condition from an already empty slice panics. An empty slice should be removed (i.e. removed idempotently) and without panicking. Originally found with , reproduced with ( at the time of writing) Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): Pop!OS 20.04 LTS Kernel (e.g. ): Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig api-machinery
cc
/assign
/triage accepted
Change:
be evicted if the taint is removed before toleration time ends. release: v1.16 file: test/e2e/node/taints.go <ins> - testname: Node, resource lifecycle codename: '[sig-node] Node Lifecycle should run through the lifecycle of a node [Conformance]' description: Creating and Reading a Node MUST succeed with required name retrieved. Patching a Node MUST succeed with its new label found. Listing Nodes with a labelSelector MUST succeed with only a single node found. Updating a Node MUST succeed with its new label found. Deleting the Node MUST succeed and its deletion MUST be confirmed. release: v1.32 file: test/e2e/node/node_lifecycle.go </ins> - testname: PodTemplate, delete a collection codename: '[sig-node] PodTemplates should delete a collection of pod templates [Conformance]' description: A set of Pod Templates is created with a label selector which MUST

Discussion:
[x] two weeks soak end date : 2024-09-08 According to following APIsnoop query, there are two Node endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 2 endpoints. The e2e logs for this test are listed below. This query shows the following Node endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/sig node
/reopen Tracking the next steps to conformance
Reopened this issue. <detailsIn response to : /reopen Tracking the next steps to conformance 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
/reopen Tracking the final step
Reopened this issue. <detailsIn response to : /reopen Tracking the final step 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:
// +optional Tolerations []Toleration // HostAliases is an optional list of hosts and IPs that will be injected into the pod's hosts <del> // file if specified. This is only valid for non-hostNetwork pods. </del> <ins> // file if specified. </ins> // +optional HostAliases []HostAlias // If specified, indicates the pod's priority. "system-node-critical" and

Discussion:
there is a note above hostAliases that this feature does not work with hostNework=true, yet it seems it does: when testing with a hostNetwork pod + hostAliases, there are no errors in kubelet logs at --v=10 related to this, in fact i don't see any hostAlias entries at all in there. i could not find anything blocking this in the kubelet, in fact there is normal handling of hostNetwork: i could not find any validation performed on the hostAliases field of PodSpec if hostNetwork is true on the API level. i could not find any unit tests or e2e tests related to this. the godoc should contain valid information if the feature is not supposed to work, it must be patched to not have the entries in the hosts file (perhaps?) we should have tests that ensure this type of requirement is guaranteed these steps confirm that a static pod with hostNework (deployed by kubeadm) does make use of hostAliases. create a kubeadm single node cluster directly with or one with modify the to include:wait some time for the new static pod spec to resync find the PID of the kube-apiserverget the hosts file n/a latest master 1.30.0-alpha.0 not applicable <details</detailskubeadm containerd v1.6.14 kindnet add test: update godoc:
/sig node network cluster-lifecycle /kind documentation
as reported by the hostAliases sometimes are not mounted for hostNetwork static pods, which is concerning: related slack thread:
At minimum the comment is wrong I need to be updated and we need e2e tests :/
found this, support was a while back: i will PR the API docs.
We identified an edge case here with Kubernetes v1.29. If a cloud provider did not yet initialise the node's , the code for creating the file including the hostAliases does not get run. To be concrete, in: is empty in this case which leads to to be . I was able to trace it back to this change which leads to this behaviour for static pods: For confirmation: I reverted the above commit, rebuilt kubelet and it got back to the old behaviour.

there is no perfect solution, but reverting is wrong because opens another bug, we need to study this more carefully but in the meantime installers that know the nodes addresses beforehand should set the --node-ip flag or not use cloud-provider external
yeah, as i mentioned downstream, revering is out of the question. it fixes some long standing problems. we might have to document somewhere this limitation in a cloud provider env.
i think it might be possible for us to special case this so that the hostAlias management does not wait for the node IP in a CP env, under certain conditions. just a speculation.
PRs add test: update godoc:
/triage accepted looks like it is being worked on already
Change:
return m } <ins> // NewLongQueueBroadcaster functions nearly identically to NewBroadcaster, // except that the incoming queue is the same size as the outgoing queues // (specified by queueLength). func NewLongQueueBroadcaster(queueLength int, fullChannelBehavior FullChannelBehavior) *Broadcaster { m := &Broadcaster{ watchers:            map[int64]*broadcasterWatcher{}, incoming:            make(chan Event, queueLength), stopped:             make(chan struct{}), watchQueueLength:    queueLength, fullChannelBehavior: fullChannelBehavior, } m.distributing.Add(1) go m.loop() return m } </ins> const internalRunFunctionMarker = "internal-do-function" // a function type we can shoehorn into the queue.

Discussion:
The standard event recorder, when recording an event, calls the underlying Broadcaster in a goroutine, so that even recording is non-blocking. Things like leader election emit events over the course of their lifecycle via this broadcaster. Consider the following scenario: GR1: spawn leader election ----GR2 GR2: Leader election: emit event "Lease Acquired" ----spawn GR3 () GR1: Shutdown leader election ----blocks until GR2 is done GR1: Shutdown broadcaster --() GR3: ----send on closed channel () Practically, we've observed this behavior popping up occaisionally in tests in controller-runtime:
/sig api-machinery /kind bug
<details<summaryrelevant race detector output/stack traces</summary</details
were you planning on sending a fix, or need our help to send one to fix it?
I can probably try to figure out a fix if you want, but the whole model for how event broadcasters currently work is inverse to how Go suggests you manage channels (only writers should ever close channels, not readers). I'll need to do a bit of playing around with things.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/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
cc
I think this is fixed by . Please reopen if it's not the case.
/triage accepted
Would be possible to cherry-pick this fix in 1.20?
Change:
r.imageClientV1alpha2 = runtimeapiV1alpha2.NewImageServiceClient(conn) } else { <del> return fmt.Errorf("unable to determine image API version: %w", err) </del> <ins> return fmt.Errorf("unable to determine image API version with %q, or API is not implemented: %w", endpoint, err) </ins> } return nil

Discussion:
When installing the latest component, got the error: Then the flag , got error: It is confusing to see these error msgs at the first glance, need to make it more clearly. Add the required field validation, and add more supportive error message. Download the latest v1.25.0 binary, and install it with systemd service or just manually start the binary, will reproduce these errors. <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
/sig node
kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions /close
Closing this issue. <detailsIn response to : kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions 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
Yes, I got to know the , so need to add runtime validation by the fix PR: PTAL thanks.
Change:
"fmt" "math/rand" "sync" <ins> "sync/atomic" </ins> "testing" "time"

Discussion:
We use a to nil out the : However on a re-sync, this results in a data race that was observed when running unit tests: The read had occurred previously during a callback. On re-sync, the retrieves every object from the cache, invokes the transform function, and re-queues them. However, the object instances are the same as those stored in the cache so mutating them outside the cache without lock protection is unsafe. It is documented that the "TransformFunc sees the object before any other actor, and it is now safe to mutate the object in place instead of making a copy" however this is not the case on a re-sync. The should make a copy of the objects retrieved from the cache store on a re-sync or perhaps elide the on a re-sync since the objects would already have been transformed. As a workaround, I changed our to only nil the if not already nil but this is a latent bug that others will likely run into.
/assign That means that and introduced possible panic regressions into kube-controller-manager and kube-scheduler /priority critical-urgent /kind regression
/transfer kubernetes
/sig api-machinery
kube-controller-manager and kube-scheduler do the same in 1.29+ and likely have the same issue
I think delete has the same problem, and replace may have the same problem: Passing the same object to the transformer after it is already in the cache is unsafe and we should not do that at all.
/assign /cc
Looking into this. I may take time to come up with a proper fix. But would like to evaluate the risk for the current situation. Not entirely sure how delete and replace would be triggered in normal settings, but resync is fortunately low frequency as the default setting for resync period is between 12h and 24h for (--min-resync-period duration Default: 12h0m0s, see ) . As for the resync function is Just think out aloud, I read a thread discussion somewhere that resync was a mechanism in the past to prevent data inconsistency due to bugs but client-go has been mature these days, resync is no-longer needed in theory but for a safe guard. So maybe disabling resync is a reasonable fix if delete/replace can be fixed.
You're mixing resync with relist - I believe relist is no longer needed. Resync is actually used.

FWIW - I opened an initial version of the fix:
I think it's resync. The thread I mentioned is
/triage accepted
Change:
return 0 } if requested > capacity { <del> glog.V(4).Infof("Combined requested resources %d from existing pods exceeds capacity %d on node %s", </del> <ins> glog.V(10).Infof("Combined requested resources %d from existing pods exceeds capacity %d on node %s", </ins> requested, capacity, node) return 0 }

Discussion:
Problem There are at least some examples of over logging in the scheduler. Solution Go through glog.Info and make sure we are consistently managing logs. At least one example to solve in an easy PR has shared with us.. Ill confirm this is happening still in upstream kube and fix as well as audit the others.
part of
yeah lets de-dupe the tickets, we have 3+ issues on this now.. closing this one. just submit the PRs and reference one of the other tickets.
Change:
<ins> # This Fluentd configuration file enables the collection of log files # that can be specified at the time of its creation in an environment # variable, assuming that the config_generator.sh script runs to generate # a configuration file for each log file to collect. # Logs collected will be sent to the Google Cloud Logging API. # # Currently the collector uses a text format rather than allowing the user # to specify how to parse each file. # # This configuration assumes the correct installation of the the Google # Fluentd plug-in, and that the VM host running this configuration is on # Google Compute Engine and has been created with the logging.write scope. # Pick up all the auto-generated input config files, one for each file # specified in the FILES_TO_COLLECT environment variable. @include files/* # All the auto-generated files should use the tag "file.<filename>". <match file.**> type google_cloud flush_interval 5s # Never wait longer than 5 minutes between retries. max_retry_wait 300 # Disable the limit on the number of retries (retry forever). disable_retry_limit </match> </ins>

Discussion:
We should provide a dockerfile for a pre-configured Fluentd image that can be passed file paths to collect logs from. We'll likely want one for exporting to elasticsearch and one for exporting to Google Cloud Logging, as we have today for the per-node stdout/stderr collectors. How to collect log files from within a container is a question that comes up occasionally (including ), and it provides a strong example of the usefulness of sidecar containers. cc
A controller that keeps one instance of a pod alive on each node would be useful for this. Shall I go ahead and write such a controller?
Would it be? This is intended to run as a sidecar container in a pod with the user's actual application. I think a pod-per-node controller is orthogonal (and is being discussed in and ). I'll create the actual Dockerfile, and a quick example of how to use it.
Sorry, my rush to catch up I think I mis-understood this thread.
Change:
if err != nil { return err } <ins> outputObj = cmdutil.AsDefaultVersionedOrOriginal(outputObj, mapping) </ins> printer, err := o.ToPrinter(operation) if err != nil {

Discussion:
https://k8s- This test is currently failing in sig-release master-blocking and upgrade suites since late 5/11. . This could potentially block Beta v1.11 which is due to be cut Tuesday,5/15. can you please help triage? /kind bug /priority failing-test /priority important-soon /sig cli cc /assign
Here are the failing upgrade jobs
Its all green now and I feel like crying :) thanks