jiebi/CodeConvo huggingface dataset:
Code change:
Write-Output $c throw "Contents of /etc/secret/foo.txt are not as expected" } <del> if ($env:NODE_NAME_TEST -ne $env:COMPUTERNAME) { throw "NODE_NAME_TEST env var ($env:NODE_NAME_TEST) does not equal COMPUTERNAME ($env:COMPUTERNAME)" </del> <ins> # Windows ComputerNames cannot exceed 15 characters, which means that the $env:COMPUTERNAME # can only be a substring of $env:NODE_NAME_TEST. We compare it with the hostname instead. # The following comparison is case insensitive. if ($env:NODE_NAME_TEST -ine "$(hostname)") { throw "NODE_NAME_TEST env var ($env:NODE_NAME_TEST) does not equal hostname" </ins> } Write-Output "SUCCESS"` )

Related discussion:
text: /assign
Just for broader context... the reason wenli discovered this is, bc we heavily test cluster API over here :), where the dynamically generated host name appends machine-set + cluster characters, so the machines have names like this: to the machines initial name, and it's hardcoded. We want to try to improve this upstream , and have a proposal to do this in flight also:
/sig windows /remove-sig testing
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active 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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
Code change:
Write-Output $c throw "Contents of /etc/secret/foo.txt are not as expected" } <del> if ($env:NODE_NAME_TEST -ne $env:COMPUTERNAME) { throw "NODE_NAME_TEST env var ($env:NODE_NAME_TEST) does not equal COMPUTERNAME ($env:COMPUTERNAME)" </del> <ins> # Windows ComputerNames cannot exceed 15 characters, which means that the $env:COMPUTERNAME # can only be a substring of $env:NODE_NAME_TEST. We compare it with the hostname instead. # The following comparison is case insensitive. if ($env:NODE_NAME_TEST -ine "$(hostname)") { throw "NODE_NAME_TEST env var ($env:NODE_NAME_TEST) does not equal hostname" </ins> } Write-Output "SUCCESS"` )

Related discussion:
text: 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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 being fixed by
Reopened this issue. <detailsIn response to : /reopen being fixed by 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
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
Code change:
Write-Output $c throw "Contents of /etc/secret/foo.txt are not as expected" } <del> if ($env:NODE_NAME_TEST -ne $env:COMPUTERNAME) { throw "NODE_NAME_TEST env var ($env:NODE_NAME_TEST) does not equal COMPUTERNAME ($env:COMPUTERNAME)" </del> <ins> # Windows ComputerNames cannot exceed 15 characters, which means that the $env:COMPUTERNAME # can only be a substring of $env:NODE_NAME_TEST. We compare it with the hostname instead. # The following comparison is case insensitive. if ($env:NODE_NAME_TEST -ine "$(hostname)") { throw "NODE_NAME_TEST env var ($env:NODE_NAME_TEST) does not equal hostname" </ins> } Write-Output "SUCCESS"` )

Related discussion:
text: This bot triages issues 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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
Code change:
} else { // Trigger immediate sync when spec is changed. jm.enqueueSyncJobImmediately(logger, curJob) <ins> } // if curJob is finished, remove the finalizer as a backup check. if IsJobFinished(curJob) { jm.backupRemovePodFinalizers(curJob) </ins> } // check if need to add a new rsync for ActiveDeadlineSeconds

Related discussion:
text: When a Job is deleted (via Background cascade), we have a backup logic to remove finalizers from pods This logic could also be applied for any finished Job. While investigating a case similar to , we observed that the job controller didn't delete finalizers from Pods where the Job was deleted with Foreground cascading policy. Since the Job was already marked as Finished, it only makes sense to trigger the backup logic to remove finalizers, so that we can guard against any possible bug where a Job is marked as Finished but not all pod finalizers are removed. Note that I'm not aware of any other bug in tracking with finalizers.
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 apps
/remove-kind feature /kind cleanup
/wg batch
I am happy to give this a go.
/assign
Just to check if I have the logic chain right: We are talking about adding this logic If so, I should probably turn the backup-logic code into a function that then apply that in both places? I also would be unsure of where in the unit tests this would be tested, are you able to point me to how this is tested in the deletePod function? I assume we add a pod that is never included in the "uncounted" lists.
I would put it in the event handler, to be more of a "catch all" Yes, that's a good idea. I think you would have to force it quite a bit, as we have fixed all the bugs that we have found. For example, from the test: the controller, but do not start the workers (this will setup the event handlers) a job the pods the job the workers some inspiration here
Alright, thank you :))
Should the issue title be: Remove finalizers from Pods belonging to finished Jobs ?
If someone has set a custom finalizer on a Pod, even one owned by a Job, (when) would we remove that finalizer?
/retitle Remove tracking finalizers from Pods belonging to finished Jobs No, only the finalizer specific to job tracking
Code change:
} templates.ActsAsRootCommand(cmds, filters, groups...) <del> cmds.AddCommand(kubectl.NewCmdVersion(f, out)) cmds.AddCommand(kubectl.NewCmdOptions(out)) </del> <ins> cmdVersion := kubectl.NewCmdVersion(f, out) cmdVersion.Example = kubefedVersionExample cmds.AddCommand(cmdVersion) cmdOptions := kubectl.NewCmdOptions(out) cmdOptions.Example = kubefedOptionsExample cmds.AddCommand(cmdOptions) </ins> return cmds }

Related discussion:
text: Referring and ; both have string in place of in section Example. This needs to be corrected in kubefed docs autogeneration. cc also see
/assign
Code change:
Expect(err).NotTo(HaveOccurred()) }() <del> // Waiting for service to expose endpoint </del> <ins> // Waiting for service to expose endpoint. </ins> validateEndpointsOrFail(c, ns, serviceName, PortsByPodName{serverPodName: {servicePort}}) By("Retrieve sourceip from a pod on the same node")

Related discussion:
text: https://k8s- Failed: [] Services should preserve source pod IP for traffic thru service cluster IP {Kubernetes e2e suite} Happened on a presubmit run in .
Sorry, it is a new e2e test I am still working on. It is not merged yet.
Don't worry about it, our flake detection isn't quite perfect yet :)
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention.
This new e2e test has been merged. Let's observe it few more days and close this issue if nothing bad happen.
[FLAKE-PING] This flaky-test issue would love to have more attention.
This does't look like a failure in new test, rather its a generic failure with serviceaccounts.
Thanks for the investigation. Yeah I think it is the serviceaccounts issue. I wonder when could we close this flaky issue. Seems like it is stable if serviceaccounts issue is fixed.
You can close it with a reference to the serviceaccounts issue - do you know the # for that one ?
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Services should preserve source pod IP for traffic thru service cluster IP {Kubernetes e2e suite}
https://k8s- Failed: [] Services should preserve source pod IP for traffic thru service cluster IP {Kubernetes e2e suite}
https://k8s- Failed: [] Services should preserve source pod IP for traffic thru service cluster IP {Kubernetes e2e suite}
https://k8s- Failed: [] Services should preserve source pod IP for traffic thru service cluster IP {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
Have a fix for this, I'm now keeping running tests on my own cluster. Will send out PR once verify the fix works.
Code change:
return converted, nil } <ins> // Deep copy the list before we invoke the converter to ensure that if the converter does mutate the // list (which it shouldn't, but you never know), it doesn't have any impact. convertedList := list.DeepCopy() convertedList.SetAPIVersion(desiredAPIVersion) </ins> convertedObjects, err := c.converter.Convert(list, toGVK.GroupVersion()) if err != nil { return nil, fmt.Errorf("conversion for %v failed: %w", in.GetObjectKind().GroupVersionKind(), err)

Related discussion:
text: If a CR converter is wired in and it modifies the input list, the delegating CR converter does not protect against this. A converter cannot effect the input list Not really possible externally - it's a coding issue that the current converters don't hit. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /assign
/triage accepted
Code change:
<g> <rect style="fill: #ffffff" x="2.35" y="476.5" width="91.3" height="54"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="2.35" y="476.5" width="91.3" height="54"/> <del> <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="48" y="499.4"> </del> <ins> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="48" y="499.4"> </ins> <tspan x="48" y="499.4">scheduling</tspan> <tspan x="48" y="515.4">actuator</tspan> </text> </g> <del> <text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="-13" y="436.75"> </del> <ins> <text font-size="12.8" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="-13" y="436.75"> </ins> <tspan x="-13" y="436.75">APIs</tspan> </text> <g>

Related discussion:
text: Architecture picture: says kubecfg is deprecated. The architecture picture should be updated to show kubectl instead of kubecfg.
ref /cc
Code change:
Expect(err).NotTo(HaveOccurred()) } <ins> func pollReadWithTimeout(pet petTester, petNumber int, key, expectedVal string) error { err := wait.PollImmediate(time.Second, readTimeout, func() (bool, error) { val := pet.read(petNumber, key) if val == "" { return false, nil } else if val != expectedVal { return false, fmt.Errorf("expected value %v, found %v", expectedVal, val) } return true, nil }) if err == wait.ErrWaitTimeout { return fmt.Errorf("timed out when trying to read value for key %v from pet %d", key, petNumber) } return err } </ins> func isInitialized(pod api.Pod) bool { initialized, ok := pod.Annotations[petset.PetSetInitAnnotation] if !ok {

Related discussion:
text: https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
The test failed because it read nothing back from the key for the "member with index 2". Looking at , I notice that it's writing to the "member with index 0" and expecting to read it back from the "member with index 2". I'm curious, is each index supposed to represent a separate redis instance? What is the consistency model here?
/cc
https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
It's master slave redis, you should be able to create the same petset with this: , fyi
https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
Code change:
Expect(err).NotTo(HaveOccurred()) } <ins> func pollReadWithTimeout(pet petTester, petNumber int, key, expectedVal string) error { err := wait.PollImmediate(time.Second, readTimeout, func() (bool, error) { val := pet.read(petNumber, key) if val == "" { return false, nil } else if val != expectedVal { return false, fmt.Errorf("expected value %v, found %v", expectedVal, val) } return true, nil }) if err == wait.ErrWaitTimeout { return fmt.Errorf("timed out when trying to read value for key %v from pet %d", key, petNumber) } return err } </ins> func isInitialized(pod api.Pod) bool { initialized, ok := pod.Annotations[petset.PetSetInitAnnotation] if !ok {

Related discussion:
text: https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
https://k8s- Failed: [] PetSet [Slow] [Feature:PetSet] [] Deploy clustered applications [Slow] [Feature:PetSet] should creating a working redis cluster [Feature:PetSet] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Code change:
var clusterIDs []string capacity := p.options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)] volSizeBytes := capacity.Value() <del> sz := int(volume.RoundUpSize(volSizeBytes, 1024*1024*1024)) </del> <ins> // Glusterfs creates volumes in units of GBs sz := int(volume.RoundUpSize(volSizeBytes, 1000*1000*1000)) </ins> glog.V(2).Infof("create volume of size: %d bytes and configuration %+v", volSizeBytes, p.provisionerConfig) if p.url == "" { glog.Errorf("REST server endpoint is empty")

Related discussion:
text: Glusterfs+Heketi use GB units for expanding volume. Using GiB incorrectly leads to expanding the volume to smaller size than user requested. /sig storage cc
Code change:
// randBytes returns a random string consisting of the characters in // validBootstrapTokenChars, with the length customized by the parameter func randBytes(length int) (string, error) { <del> // len("0123456789abcdefghijklmnopqrstuvwxyz") = 36 which doesn't evenly divide // the possible values of a byte: 256 mod 36 = 4. Discard any random bytes we // read that are >= 252 so the bytes we evenly divide the character set. const maxByteValue = 252 </del> var ( <del> b     byte err   error </del> token = make([]byte, length) <ins> max   = new(big.Int).SetUint64(uint64(len(validBootstrapTokenChars))) </ins> ) <del> reader := bufio.NewReaderSize(rand.Reader, length*2) </del> for i := range token { <del> for { if b, err = reader.ReadByte(); err != nil { return "", err } if b < maxByteValue { break } </del> <ins> val, err := rand.Int(rand.Reader, max) if err != nil { return "", fmt.Errorf("could not generate random integer: %w", err) </ins> } <del> token[i] = validBootstrapTokenChars[int(b)%len(validBootstrapTokenChars)] </del> <ins> // Use simple operations in constant-time to obtain a byte in the a-z,0-9 // character range x := val.Uint64() res := x + 48 + (39 & ((9 - x) >> 8)) token[i] = byte(res) </ins> } return string(token), nil

Related discussion:
text: The vendor considers this issue Informational Risk, High Impact, Undetermined Exploitability To view the original finding, begin on page 42 of the Test Environment Kubernetes 1.24.3
/sig security
/sig cluster-lifecycle
/assign
PR that attempts to fix this:
/triage accepted poked #sig-security at slack for review ^
Code change:
}, { in: &api.Pod{ <ins> Spec: api.PodSpec{ServiceAccountName: "serviceAccount1"}, }, fieldSelector: fields.ParseSelectorOrDie("spec.serviceAccountName=serviceAccount1"), expectMatch:   true, }, { in: &api.Pod{ Spec: api.PodSpec{SchedulerName: "serviceAccount1"}, }, fieldSelector: fields.ParseSelectorOrDie("spec.serviceAccountName=serviceAccount2"), expectMatch:   false, }, { in: &api.Pod{ </ins> Status: api.PodStatus{Phase: api.PodRunning}, }, fieldSelector: fields.ParseSelectorOrDie("status.phase=Running"),

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When trying to list object using field spec.ServiceAccountName, we are getting the below error message. field label not supported: spec.serviceAccountName What you expected to happen: To be able to fetch pods using the list and watch based on the field 'spec.serviceAccountName' How to reproduce it (as minimally and precisely as possible): in minikube run Anything else we need to know?: Description: Unable to fetch pods based on the field 'spec.serviceAccountName'. When trying to get an overview of RBAC privileges in a cluster it is hard to find the objects attached to service accounts Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-27T20:08:34Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: minikube version: v0.28.0 OS (e.g. from /etc/os-release): NAME=Buildroot VERSION=2018.05 ID=buildroot VERSIONID=2018.05 PRETTYNAME="Buildroot 2018.05" Kernel (e.g. ): Linux minikube 4.16.14 SMP Mon Jun 11 16:20:15 UTC 2018 x86_64 GNU/Linux Install tools: kubeadm Others:
/sig architecture
You might do it by jsonpath filter
I intend to utilize it in the client-go list as an option
Not all fields are supported for field selector. There is a doc about field selector which is still under review: As far as I can see, supported field selectors for pods are listed here:
Didn't find that you have a pull request for it. :) Good luck!
Code change:
"fmt" "io/ioutil" "os" <ins> "sort" </ins> "strings" "testing"

Related discussion:
text: /kind bug What happened: When building kubernetes-1.7.0 packages for openSUSE, results differ for each build in and other man pages. coming from that uses and probably sets do not have any specific order, so it would need to be sorted on output. What you expected to happen: Every build should give identical results. See https://reproducible- for why this matters. How to reproduce it (as minimally and precisely as possible): See Anything else we need to know?: Environment: Kubernetes version: 1.7.0 OS (e.g. from /etc/os-release): openSUSE Tumbleweed
/sig release
somehow this bug seems to have been forgotten - can you help getting the right people to have a look?
- can you please confirm that PR works for you?
I tested it and it looks good.
/assign I enjoy reading my highlights to find the issue has already been addressed. :)
Sorry this wasn't addressed sooner. It does seem like it fell into a black hole, and pinging was the right way to resolve that. :)
/area build-release
related to /reopen
Reopening this issue. <detailsIn response to : related to 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