jiebi/CodeConvo huggingface dataset:
Code change:
t.Error("unexpected cache keys") } } <ins> func Test_ExecPluginEnvVars(t *testing.T) { testcases := []struct { name            string systemEnvVars   []string execPlugin      *execPlugin expectedEnvVars []string }{ { name:          "positive append system env vars", systemEnvVars: []string{"HOME=/home/foo", "PATH=/usr/bin"}, execPlugin: &execPlugin{ envVars: []kubeletconfig.ExecEnvVar{ { Name:  "SUPER_SECRET_STRONG_ACCESS_KEY", Value: "123456789", }, }, }, expectedEnvVars: []string{ "HOME=/home/foo", "PATH=/usr/bin", "SUPER_SECRET_STRONG_ACCESS_KEY=123456789", }, }, { name:          "positive no env vars provided in plugin", systemEnvVars: []string{"HOME=/home/foo", "PATH=/usr/bin"}, execPlugin:    &execPlugin{}, expectedEnvVars: []string{ "HOME=/home/foo", "PATH=/usr/bin", }, }, { name: "positive no system env vars but env vars are provided in plugin", execPlugin: &execPlugin{ envVars: []kubeletconfig.ExecEnvVar{ { Name:  "SUPER_SECRET_STRONG_ACCESS_KEY", Value: "123456789", }, }, }, expectedEnvVars: []string{ "SUPER_SECRET_STRONG_ACCESS_KEY=123456789", }, }, { name:            "positive no system or plugin provided env vars", execPlugin:      &execPlugin{}, expectedEnvVars: nil, }, { name:          "positive plugin provided vars takes priority", systemEnvVars: []string{"HOME=/home/foo", "PATH=/usr/bin", "SUPER_SECRET_STRONG_ACCESS_KEY=1111"}, execPlugin: &execPlugin{ envVars: []kubeletconfig.ExecEnvVar{ { Name:  "SUPER_SECRET_STRONG_ACCESS_KEY", Value: "123456789", }, }, }, expectedEnvVars: []string{ "HOME=/home/foo", "PATH=/usr/bin", "SUPER_SECRET_STRONG_ACCESS_KEY=1111", "SUPER_SECRET_STRONG_ACCESS_KEY=123456789", }, }, } for _, testcase := range testcases { t.Run(testcase.name, func(t *testing.T) { testcase.execPlugin.environ = func() []string { return testcase.systemEnvVars } var configVars []string for _, envVar := range testcase.execPlugin.envVars { configVars = append(configVars, fmt.Sprintf("%s=%s", envVar.Name, envVar.Value)) } merged := mergeEnvVars(testcase.systemEnvVars, configVars) err := validate(testcase.expectedEnvVars, merged) if err != nil { t.Logf("unexpecged error %v", err) } }) } } func validate(expected, actual []string) error { if len(actual) != len(expected) { return errors.New(fmt.Sprintf("actual env var length [%d] and expected env var length [%d] don't match", len(actual), len(expected))) } for i := range actual { if actual[i] != expected[i] { return fmt.Errorf("mismatch in expected env var %s and actual env var %s", actual[i], expected[i]) } } return nil } </ins>

Related discussion:
text: Thanks for looking into the issue, you are right the spec does says that. Feel free to fix it /triage accepted
Thanks!!!
/area kubelet
: I am facing the similar issue on my bare metal cluster This is my config Can you help. It works when I try to execute the credentials binary from local but doesn't work in the pod. Can you pls guide me
I've been fighting this for days - did you ever figure it out?
Code change:
import ( "context" <ins> "strings" </ins> "testing" v1 "k8s.io/api/core/v1"

Related discussion:
text: Running kubectl create with dry-run returns unwanted uid metadata field, as well as a generated name when using generateName. This is inconsistent with the expectations as defined in which states I expected uid, and a generated name to be empty when using the dry-run create option. Expected metadata: Actual metadata: No response <detailsI've tested this from 1.19.0 through 1.23.0 </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/assign /triage accepted
reopening, is reverted in to make sure requests with both name+generateName are handled correctly
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 .
Code change:
import ( "context" <ins> "strings" </ins> "testing" v1 "k8s.io/api/core/v1"

Related discussion:
text: /close [1]:
Closing this issue. <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 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
Code change:
id, err := getDiskID(pdName, exec) if err != nil { klog.Errorf("WaitForAttach (windows) failed with error %s", err) <ins> return "", err </ins> } <del> return id, err </del> <ins> return id, nil </ins> } partition := ""

Related discussion:
text: In the implement of GCE mode WaitForAttach: when the runtime.GOOS = "windows" and it meets err , it should instead of . the code should be like this : None The modification is in order to match the code cosistant pattern. Any GCE Any Any Any Any
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 cloud-provider
/assign
/assign
Code change:
resyncCh, cleanup := r.resyncChan() defer cleanup() <del> options := unversioned.ListOptions{} </del> <ins> // Explicitly set "0" as resource version - it's fine for the List() // to be served from cache and potentially be delayed relative to // etcd contents. Reflector framework will catch up via Watch() eventually. options := unversioned.ListOptions{ResourceVersion: "0"} </ins> list, err := r.listerWatcher.List(options) if err != nil { return fmt.Errorf("%s: Failed to list %v: %v", r.name, r.expectedType, err)

Related discussion:
text: The label(s) cannot be applied. These labels are supported: <detailsIn response to : This one is trying to use with a generator to create an rc. This was deprecated and now is removed, so the test is failing now. /label sig/undefined 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
/label failing-test
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label failing-test 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
/kind failing-test
At first I thought this was because generators were removed from . That still might be the cause of this, but I'm not 100% sure off-hand.
/sig cli
/assign
Funny thing about this is if you look in the build logs it is not immediately obvious that it is caused by generators being removed from because actually has sort of an unexpected behavior, where it tells you it is deprecated and gives you a pod instead... For example: Output:
/reopen should fix this is one of the affected jobs
Reopened this issue. <detailsIn response to : /reopen should fix this 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
Since it's been a few weeks, I wanted to provide an update on this. I'm still waiting to confirm this is resolved by It looks like it is still running the old tests not marked as . Since 1.17.9 was released 14 days ago, and k8s-ci-robot only merged the PR 13 days ago, I'm guessing we need to wait until there is a 1.17.10 to see it skip the deprecated tests.
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.
Code change:
resyncCh, cleanup := r.resyncChan() defer cleanup() <del> options := unversioned.ListOptions{} </del> <ins> // Explicitly set "0" as resource version - it's fine for the List() // to be served from cache and potentially be delayed relative to // etcd contents. Reflector framework will catch up via Watch() eventually. options := unversioned.ListOptions{ResourceVersion: "0"} </ins> list, err := r.listerWatcher.List(options) if err != nil { return fmt.Errorf("%s: Failed to list %v: %v", r.name, r.expectedType, err)

Related discussion:
text: 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
Code change:
_, status := getFinishedStatus(j) deleteFromActiveList(cj, j.ObjectMeta.UID) jm.recorder.Eventf(cj, corev1.EventTypeNormal, "SawCompletedJob", "Saw completed job: %s, status: %v", j.Name, status) <ins> } else if IsJobFinished(j) { // a job does not have to be in active list, as long as it is finished, we will process the timestamp if cj.Status.LastSuccessfulTime == nil { cj.Status.LastSuccessfulTime = j.Status.CompletionTime } if j.Status.CompletionTime != nil && j.Status.CompletionTime.After(cj.Status.LastSuccessfulTime.Time) { cj.Status.LastSuccessfulTime = j.Status.CompletionTime } </ins> } }

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Cronjob should include the last time when a job was successfully completed. Why is this needed: Currently, a Cronjob's only includes the last time when a job was scheduled. This makes monitoring cronjobs much more complicated, because instead of simply comparing to the current timestamp, the monitoring system now has to hunt for the last job related to the cronjob and persist the state somewhere.
Reiterating the mentions to trigger a notification: <detailsIn response 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
I'd be interesting in picking this up if the apps team thinks this is a good ticket - it seems like it's fairly beginner friendly.
Hi how is this going on? I could take it over if you don't have the time for this issue. :)
Yes please do! I meant to update that I actually wasn't able to pick this up, but it slipped my mind
/assign
Hi do you have any thoughts on this feature?
/unassign
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
Any updates?
Reiterating the mentions to trigger a notification: <detailsIn response to : Any updates? 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
Trying to understand the usage of lastSuccessfulTime. In a normally working case, lastSuccessfulTime lastScheduledTime =last job completed lastSuccessfulTime < lastScheduledTime =last job completed, but a newer one is running Is that the expectation ?
We wanted to use it in monitoring (e.g. fire an alert if is more than X ago). could also mean that the job has been failing for some time, so I don't know what would you get out of that. I guess you could also use as a proxy for "job has failed at least once"?
Code change:
_, status := getFinishedStatus(j) deleteFromActiveList(cj, j.ObjectMeta.UID) jm.recorder.Eventf(cj, corev1.EventTypeNormal, "SawCompletedJob", "Saw completed job: %s, status: %v", j.Name, status) <ins> } else if IsJobFinished(j) { // a job does not have to be in active list, as long as it is finished, we will process the timestamp if cj.Status.LastSuccessfulTime == nil { cj.Status.LastSuccessfulTime = j.Status.CompletionTime } if j.Status.CompletionTime != nil && j.Status.CompletionTime.After(cj.Status.LastSuccessfulTime.Time) { cj.Status.LastSuccessfulTime = j.Status.CompletionTime } </ins> } }

Related discussion:
text: 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
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
/remove-lifecycle rotten
that's exactly what is being asked here. /close
Closing this issue. <detailsIn response to : /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
"successfully scheduled" != "successfully completed", and most of the users care more about the latter.
/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
/assign /triage accepted
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-contributor-experience at .
Code change:
_, status := getFinishedStatus(j) deleteFromActiveList(cj, j.ObjectMeta.UID) jm.recorder.Eventf(cj, corev1.EventTypeNormal, "SawCompletedJob", "Saw completed job: %s, status: %v", j.Name, status) <ins> } else if IsJobFinished(j) { // a job does not have to be in active list, as long as it is finished, we will process the timestamp if cj.Status.LastSuccessfulTime == nil { cj.Status.LastSuccessfulTime = j.Status.CompletionTime } if j.Status.CompletionTime != nil && j.Status.CompletionTime.After(cj.Status.LastSuccessfulTime.Time) { cj.Status.LastSuccessfulTime = j.Status.CompletionTime } </ins> } }

Related discussion:
text: /lifecycle rotten
This is described in and being actively implemented in /close
Closing this issue. <detailsIn response to : This is described in and being actively implemented in /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
It doesn't look like it was actually implemented, though. Searching for only shows API changes, there don't seem to be any changes to the CronJob controller logic. Or am I missing something?
/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
/assign /remove-lifecycle rotten
Code change:
func (f fakeRL) TryAccept() bool { return bool(f) } func (f fakeRL) Accept()         {} <del> func expectHTTP(url string, code int, t *testing.T) { </del> <ins> func expectHTTP(url string, code int) error { </ins> r, err := http.Get(url) if err != nil { <del> t.Errorf("unexpected error: %v", err) return </del> <ins> return fmt.Errorf("unexpected error: %v", err) </ins> } if r.StatusCode != code { <del> t.Errorf("unexpected response: %v", r.StatusCode) </del> <ins> return fmt.Errorf("unexpected response: %v", r.StatusCode) </ins> } <ins> return nil </ins> } func getPath(resource, namespace, name string) string {

Related discussion:
text: Have only seen this once, personally.
This flaked in Jenkins as well. [job/kubernetes-test-go/5351]
can you take a look at this? I think has a lot already :)
Code change:
if err != nil { t.Fatal(err) } <del> if res.StatusCode != http.StatusGatewayTimeout { t.Errorf("got res.StatusCode %d; expected %d", res.StatusCode, http.StatusServiceUnavailable) </del> <ins> if actual, expected := res.StatusCode, http.StatusGatewayTimeout; actual != expected { t.Errorf("got status code %d; expected %d", actual, expected) </ins> } res.Body.Close() }

Related discussion:
text: Similar to and easily reproducible. The handler occasionally completes and sends a response before timing out. /kind failing-test /kind flake /sig api-machinery
/assign
/assign Thank you very much for fixing these tests.
/triage accepted
Code change:
LoadBalancer } <ins> type empty struct{} </ins> func networkExtensions(client *gophercloud.ServiceClient) (map[string]bool, error) { seen := make(map[string]bool)

Related discussion:
text: LBaaS implementation (v1 or v2) will not support services that require to load balancer more than one port.
Fixed for LBaaS v2 by I suspect LBaaS v1 can't support multiple ports (not sure if reusing the VIP across multiple loadbalancers is a universally supported thing). I also believe LBaaS v1 is also mostly gone in favour of v2 in deployments so trying to address this in v1 is extremely low priority unless someone steps forward to ask for it. So: I think we can close this bug now, but I lack the powers to do that directly.
thank you for the update.
Code change:
pod.Spec.PriorityClassName = pcName } else { pcName := pod.Spec.PriorityClassName <del> if !priorityClassPermittedInNamespace(pcName, a.GetNamespace()) { return admission.NewForbidden(a, fmt.Errorf("pods with %v priorityClass is not permitted in %v namespace", pcName, a.GetNamespace())) </del> <ins> // If ResourceQuotaScopeSelectors is enabled, we should let pods with critical priorityClass to be created // any namespace where administrator wants it to be created. if !p.resourceQuotaFeatureGateEnabled { if !priorityClassPermittedInNamespace(pcName, a.GetNamespace()) { return admission.NewForbidden(a, fmt.Errorf("pods with %v priorityClass is not permitted in %v namespace", pcName, a.GetNamespace())) } </ins> } // Try resolving the priority class name.

Related discussion:
text: <!-- 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: Following the documentation at the , I tried enabling quota for a namespace other than but I was still not able to create a pod with priorityClass in my namespace with following error: Error from server (Forbidden): error when creating "": pods "memory-demo" is forbidden: pods with system-cluster-critical priorityClass is not permitted in my-namespace namespace What you expected to happen: Expected pod to be created with namespace where I allowed quota. I can see that both ResourceQuota and Priority Plugins are enabled from logs. I0408 17:15:08. ] Loaded 8 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,LimitRanger,ServiceAccount,TaintNodesByCondition,Priority,DefaultTolerationSeconds,DefaultStorageClass,MutatingAdmissionWebhook. I0408 17:15:08. ] Loaded 6 validating admission controller(s) successfully in the following order: LimitRanger,ServiceAccount,Priority,PersistentVolumeClaimResize,ValidatingAdmissionWebhook,ResourceQuota. How to reproduce it (as minimally and precisely as possible): Follow the steps at Anything else we need to know?: I think, the issue is with priorityPlugin where we are rejecting instead of letting resourceQuota plugin to handle the admission when is enabled. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig scheduling /cc
Same happens to me. Correction, it does not allow to use the default permissions outside of kube-system
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
See also:
/remove-lifecycle stale
/assign Per offline discussion with
Same issue here.
Code change:
pod.Spec.PriorityClassName = pcName } else { pcName := pod.Spec.PriorityClassName <del> if !priorityClassPermittedInNamespace(pcName, a.GetNamespace()) { return admission.NewForbidden(a, fmt.Errorf("pods with %v priorityClass is not permitted in %v namespace", pcName, a.GetNamespace())) </del> <ins> // If ResourceQuotaScopeSelectors is enabled, we should let pods with critical priorityClass to be created // any namespace where administrator wants it to be created. if !p.resourceQuotaFeatureGateEnabled { if !priorityClassPermittedInNamespace(pcName, a.GetNamespace()) { return admission.NewForbidden(a, fmt.Errorf("pods with %v priorityClass is not permitted in %v namespace", pcName, a.GetNamespace())) } </ins> } // Try resolving the priority class name.

Related discussion:
text: We are using namespaces other than kube-system for system pods as it is getting too crowded, therefore we would like to run cluster-node-critical pods in other namespaces.
Waiting for this to be available myself. No reason my Node Exporter dataset has to run in the namespace instead of my namespace.