jiebi/CodeConvo huggingface dataset:
Change:
gatherMetrics(f) }) <ins> // deleteOptions.OrphanDependents is deprecated in 1.7 and preferred to use the PropagationPolicy. // Discussion is tracked under https://github.com/kubernetes/kubernetes/issues/65427 to promote for conformance in future. </ins> It("should orphan pods created by rc if deleteOptions.OrphanDependents is nil", func() { clientSet := f.ClientSet rcClient := clientSet.CoreV1().ReplicationControllers(f.Namespace.Name)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: With respect to the to promote e2e tests for conformance, while going through codebase, It is observed that this e2e test case is using deprecated (in 1.7) (OrphanDependents=nil). So we may not promote it to conformance as it is not meeting the . What you expected to happen: not promote this e2e tests for conformance. another e2e test with deleteOptions parameters as propagationPolicy="Orphan" to achieve same behaviour. Anything else we need to know?: Any suggestion or feedback is expected in order to promote this e2e test. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: cc /area conformance
Reiterating the mentions to trigger a notification: <detailsIn response to : <!-- This form is for bug reports and feature requests ONLY! --/kind feature /kind bug /kind feature What happened: With respect to the to promote e2e tests for conformance, while going through codebase, It is observed that this e2e test case is using deprecated (in 1.7) (OrphanDependents=nil). So we may not promote it to conformance as it is not meeting the . Do not promote this e2e tests for conformance. Create another e2e test with deleteOptions parameters as propagationPolicy="Orphan" to achieve same behaviour. Any suggestion or feedback is expected in order to promote this e2e test. Kubernetes version (use ):OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /area 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
your guidance on this will be helpful. Should we consider rewriting the e2e test and then promote it?

/cc who is on the blamelist for this test
As discussed offline in an email thread, can help rewrite the test as long as there's some guidance to help him get started.
So as per your observation here there's already a conformance test for deleteOptions? Ref: and let us know if the test referenced above tests the functionality fully or you need it updated.
Yes mentioned conformance test is verifying GC behavior with Orphan propagation.
based on discussion offline, it sounds like we don't want to bother promoting to conformance because is deprecated, let's document this next to the test to close this out, so we don't lose track and try promoting this in the future
Change:
__kubectl_filedir() { local RET OLD_IFS w qw <del> __debug "_filedir $@ cur=$cur" </del> <ins> __kubectl_debug "_filedir $@ cur=$cur" </ins> if [[ "$1" = ~* ]]; then # somehow does not work. Maybe, zsh does not call this at all eval echo "$1"

Discussion:
/kind bug I wasn't able to find issue opened for ZSH case, and aware about similar, fixed, case with bash in 1.10.0-b1 bash completion is working fine
/sig cli
can you verify this and label for v1.10 milestone and note if it will be considered a release blocker
I cannot reproduce this on my local machine (zsh 5.3.1 x86_64-apple-darwin16.3.0). Please produce a docker container (with Dockerfile) that shows this issue.
And another important question for the release: can you try with the 1.9 kubectl? Is that working in your setup?
little bit more info: i'm running this on CentOS 7.4 1708 x64 and zsh from official repo same issue happenes with 1.10.0-b3: 3
From sig-cli Slack: Kazuki Suda [01:22] It seems that have to be renamed to due to changes contained (edited)
You can reproduce this with the below:
was renamed to at , but has been used yet in completions generated by . So we have to replace to .
issue still exists with v10.0.0-b4
10.0-beta.4 does not contain the fix, yet.
Because the fix is not cherry-picked to release-1.10 yet.
Change:
// components in the returned string are not modified (in other words are not // replaced with symlinks on the filesystem) after this function has returned. // Such a symlink race is necessarily out-of-scope of SecureJoin. <ins> // // Volume names in unsafePath are always discarded, regardless if they are // provided via direct input or when evaluating symlinks. Therefore: // // "C:Temp" + "D:pathtofile.txt" results in "C:Temppathtofile.txt" </ins> func SecureJoinVFS(root, unsafePath string, vfs VFS) (string, error) { // Use the os.* VFS implementation if none was specified. if vfs == nil { vfs = osVFS{} } <ins> unsafePath = filepath.FromSlash(unsafePath) </ins> var path bytes.Buffer n := 0 for unsafePath != "" { if n > 255 { <del> return "", &os.PathError{Op: "SecureJoin", Path: root + "/" + unsafePath, Err: syscall.ELOOP} </del> <ins> return "", &os.PathError{Op: "SecureJoin", Path: root + string(filepath.Separator) + unsafePath, Err: syscall.ELOOP} } if v := filepath.VolumeName(unsafePath); v != "" { unsafePath = unsafePath[len(v):] </ins> } // Next path component, p.

Discussion:
One of the dependencies of k8s, filepath-securejoin, has a following vulnerability discovered: It has been patched in version 0.2.4, however k8s is still using version 0.2.3. Potential fix: updating the dependency. A small PR will follow. /sig security
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 security
/kind bug /sig security
Change:
run(ctx, nil, createInitializersFunc(leaderMigrator.FilterFunc, leadermigration.ControllerMigrated)) }, OnStoppedLeading: func() { <del> klog.Fatalf("migration leaderelection lost") </del> <ins> klog.ErrorS(nil, "migration 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:
ginkgo.DeferCleanup(cleanup) }) <del> ginkgo.It("should block a second pod from using an in-use ReadWriteOncePod volume", func(ctx context.Context) { </del> <ins> ginkgo.It("should preempt lower priority pods using ReadWriteOncePod volumes", func(ctx context.Context) { </ins> // Create the ReadWriteOncePod PVC. accessModes := []v1.PersistentVolumeAccessMode{v1.ReadWriteOncePod} l.volume = storageframework.CreateVolumeResourceWithAccessModes(ctx, driver, l.config, pattern, t.GetTestSuiteInfo().SupportedSizeRange, accessModes) <ins> l.priorityClass = &schedulingv1.PriorityClass{ ObjectMeta: metav1.ObjectMeta{Name: "e2e-test-read-write-once-pod-" + string(uuid.NewUUID())}, Value:      int32(1000), } _, err := l.cs.SchedulingV1().PriorityClasses().Create(ctx, l.priorityClass, metav1.CreateOptions{}) framework.ExpectNoError(err, "failed to create priority class") </ins> podConfig := e2epod.Config{ NS:           f.Namespace.Name, PVCs:         []*v1.PersistentVolumeClaim{l.volume.Pvc},

Discussion:
For 1.27 we should graduate the ReadWriteOncePod feature to beta. This is needed to rollout the feature to GA. In beta this feature will support preemption of pods using PVCs. See:
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 storage /sig scheduling
Change:
if len(p.Status.NominatedNodeName) == 0 { continue } <del> podCopy := p.DeepCopy() podCopy.Status.NominatedNodeName = "" if err := PatchPod(cs, p, podCopy); err != nil { </del> <ins> podStatusCopy := p.Status.DeepCopy() podStatusCopy.NominatedNodeName = "" if err := PatchPodStatus(cs, p, podStatusCopy); err != nil { </ins> errs = append(errs, err) } }

Discussion:
I am aware that the following is a corner case that does not occur in day-to-day business, but it took me a long while to debug, so I thought I would raise this issue to save others from the same pain. Deploying the following job with empty imagePullSecrets leads to it being stuck in forever, and status looking the following way: The status should look something like: This would allow my autoscaler to kick in and add the corresponding nodes. Run Kubernetes version (use ):Cloud provider or hardware configuration: AWS EKS OS (e.g: ): MacOSX 11.3 Kernel (e.g. ): Darwin Kernel Version 20.4.0 Install tools: brew
/sig scheduling (I assume)
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig scheduling (I assume) 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
/assign Scheduler log
Should we instead forbid empty items in ? Is there a use case for using as ?
For me personally that would be totally fine I had no use case for it. It was more produced by chance as I wasn't aware that I had to handle the case separately. An error which led to an early failure would have been fine by me and solved all my problems in tracking this down.
/assign as
Forbidding it is the appropriate solution. However, we can't do it for backwards compatibility of the API. /triage accepted
Change:
[Metadata] search-order = configDrive, metadataService `)) <ins> cfg.Global.Password = os.Getenv("OS_PASSWORD") </ins> if err != nil { t.Fatalf("Should succeed when a valid config is provided: %s", err) }

Discussion:
This issue was reported in the Description When configuring components of infrastructure, environment variables allow a trivial method of gathering settings. However, not all settings should be derived from these variables. For example, the file used the CFSSLCAPKPASSWORD environment variable, where a plain-text password should be found within the variable. Figure 8.1: A string password being recovered from the CFSSLCAPKPASSWORD environment variable. If this variable is configured, an attacker could potentially gain access to its stored value through environment logging, or further exploitation of the endpoint. The assessment team found seemingly sensitive environment variables in at least the following locations: Exploit Scenario Alice configures her environment with the CFSSLCAPKPASSWORD environment variable. Eve gains access to Alice’s environment and determines that the CFSSLCAPK_PASSWORD environment variable is set. Because this variable contains the private key password, Eve is able to recover the private key and use it trivially, leading to further exploitation of Alice’s environment. Recommendation Short term, ensure highly sensitive information is not collected directly from environment variables for long periods of time. Long term, consider using Kubernetes secrets for all areas of the system. This will allow users to have one unified interface and location for all secrets, and avoid accidentally exposing secrets to other users within a host system. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of TOB-K8S-005 and it was finding 9 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 35 of the Environment: Kubernetes version: 1.13.4
/sig auth /sig cloud-provider /area security /kind bug /remove-kind feature
Also secrets
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?
is it ok to close this issue also cc:
no, still remains
cc
seen this yet?
Thanks for the attention, we are using it as a fallback option mostly for test and dev env, we are working to remove them.
AFAIK is the only use for this testing. Would it be appropriate to move this code into ?
Submitted a PR to move password retrieval to
Change:
func (plugin *nfsPlugin) newUnmounterInternal(volName string, podUID types.UID, mounter mount.Interface) (volume.Unmounter, error) { return &nfsUnmounter{&nfs{ <del> volName: volName, mounter: mounter, pod:     &v1.Pod{ObjectMeta: metav1.ObjectMeta{UID: podUID}}, plugin:  plugin, </del> <ins> volName:         volName, mounter:         mounter, pod:             &v1.Pod{ObjectMeta: metav1.ObjectMeta{UID: podUID}}, plugin:          plugin, MetricsProvider: volume.NewMetricsStatFS(getPath(podUID, volName, plugin.host)), </ins> }}, nil }

Discussion:
/kind feature What happened: on a cluster with an nfs persistent volume present: What you expected to happen: I expected metrics concerning the nfs persistent volume to be returned e.g: (from a separate aws cluster) Anything else we need to know?: I'm assuming that this is just not implemented currently? I couldn't find a referencing issue Environment: Kubernetes version (use ):Cloud provider or hardware configuration: on-prem OS (e.g. from /etc/os-release):Kernel (e.g. ):
/sig instrumentation
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/open Metrics is missing for NFS driver.
/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
/remove-lifecycle rotten
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
/sig storage
Change:
[Install] WantedBy=kubernetes.target <ins> - path: /etc/systemd/system/kube-master-internal-route.service permissions: 0644 owner: root content: | [Unit] Description=Configure kube internal route After=kube-master-installation.service [Service] Type=oneshot RemainAfterExit=yes ExecStartPre=/usr/bin/curl --fail --retry 5 --retry-delay 3 --silent --show-error -H "X-Google-Metadata-Request: True" -o /home/kubernetes/bin/kube-master-internal-route.sh http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-master-internal-route ExecStartPre=/bin/chmod 544 /home/kubernetes/bin/kube-master-internal-route.sh ExecStart=/home/kubernetes/bin/kube-master-internal-route.sh [Install] WantedBy=kubernetes.target </ins> - path: /etc/systemd/system/kube-master-configuration.service permissions: 0644 owner: root

Discussion:
If you create a private cluster via kube-up using provider GCE, you won't be able to restart your master nodes. If you restart you master, the nodes won't be able to connect to your master. This is due to this line - It gets executed on master on cluster-up, but it won't be re-executed on master restart. We should fix that, especially if we're to implement /sig scalability /priority important-soon
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
/remove-lifecycle stale /good-first-issue I'll ask whether someone in SIG Scalability public meeting would like to take on this one
This request has been marked as suitable for new contributors. 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 : /remove-lifecycle stale /good-first-issue 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
Hello, Can I start work on this one as my first issue? :)
I don't see anyone else claiming it, so your contributions are welcome :)
let me know if you need any explanations here
Thank you :) I've made some changes and assign you can you tell me is this will be good approach?
Thanks, I replied in the PR
Change:
KUBE_PROMPT_FOR_UPDATE=y KUBE_SKIP_UPDATE=${KUBE_SKIP_UPDATE-"n"} <ins> function join_csv { local IFS=','; echo "$*"; } </ins> # Verify prereqs function verify-prereqs { local cmd

Discussion:
This happens over and over. Scary messages. WARNING: Lists should be separated by commas, try "--allow=tcp,udp,icmp,esp,ah,sctp". If you intend to use udp, icmp, esp, ah, sctp for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--scopes=storage-ro,compute-rw". If you intend to use compute-rw for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--metadata-from-file=startup-script=/usr/local/google/home/thockin/src/kubernetes/hack/e2e-internal/../../cluster/../cluster/gce/../../cluster/../cluster/gce/configure-,kube-env=/tmp/kubernetes.MURmzX/master-kube-". If you intend to use kube-env=/tmp/kubernetes.MURmzX/master-kube- for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--disk=name=e2e-test-thockin-master-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no". If you intend to use device-name=master-pd, mode=rw, boot=no, auto-delete=no for positional arguments, put them before the flag.
That's a new one. gcloud started getting a little more anal here. Exciting. cc
They changed list argument syntax a while back, but the warnings are new. Time to update startup scripts I guess.
Change:
<ins> //go:build !linux // +build !linux /* Copyright 2024 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package inuserns // RunningInUserNS detects whether the current process is running in a user namespace. func RunningInUserNS() bool { return false } </ins>

Discussion:
is no longer compilable on macOS in the master branch. It was compilable with Kubernetes v1.29.0 and v1.30.0-alpha.0. It should be compilable. No response <detailsmaster () (This is just the latest commit, not the commit that introduced the regression) </details<detailsN/A </details<detailsmacOS 14.2.1 (Intel) </details<detailsN/A </details<detailsN/A </details<detailsN/A </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 testing
Regression in:
Change:
# svc1:8080 with a tls secret "my-cert" kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert" <del> # Create a catch all ingress pointing to service svc:port and Ingress Class as "otheringress" kubectl create ingress catch-all --class=otheringress --rule="_/=svc:port" </del> <ins> # Create a catch all ingress of "/path" pointing to service svc:port and Ingress Class as "otheringress" kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port" </ins> # Create an ingress with two annotations: ingress.annotation1 and ingress.annotations2 kubectl create ingress annotated --class=default --rule="foo.com/bar=svc:port" 

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: kubectl create ingress panics because there is no cmdutil.AddDryRunFlag What you expected to happen: Command to work How to reproduce it (as minimally and precisely as possible): Compile the upstream, run ` Anything else we need to know?: Environment: Kubernetes version (use ): upstream/dev /sig cli /kind bug /priority critical-urgent
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