jiebi/CodeConvo huggingface dataset:
Code change:
return "", err } <ins> pc := d.Core().Pods(namespace) mountPods, err := getMountPods(pc, pvc.Name) if err != nil { return "", err } </ins> events, _ := d.Core().Events(namespace).Search(legacyscheme.Scheme, pvc) <del> return describePersistentVolumeClaim(pvc, events) </del> <ins> return describePersistentVolumeClaim(pvc, events, mountPods) } func getMountPods(c coreclient.PodInterface, pvcName string) ([]api.Pod, error) { nsPods, err := c.List(metav1.ListOptions{}) if err != nil { return []api.Pod{}, err } var pods []api.Pod for _, pod := range nsPods.Items { pvcs := getPvcs(pod.Spec.Volumes) for _, pvc := range pvcs { if pvc.PersistentVolumeClaim.ClaimName == pvcName { pods = append(pods, pod) } } } return pods, nil </ins> } <del> func describePersistentVolumeClaim(pvc *api.PersistentVolumeClaim, events *api.EventList) (string, error) { </del> <ins> func getPvcs(volumes []api.Volume) []api.Volume { var pvcs []api.Volume for _, volume := range volumes { if volume.VolumeSource.PersistentVolumeClaim != nil { pvcs = append(pvcs, volume) } } return pvcs } func describePersistentVolumeClaim(pvc *api.PersistentVolumeClaim, events *api.EventList, mountPods []api.Pod) (string, error) { </ins> return tabbedString(func(out io.Writer) error { w := NewPrefixWriter(out) w.Write(LEVEL_0, "Name:t%sn", pvc.Name)

Related discussion:
text: However it will meet an error if the pod have no volumes, so I improves it by adding a to check whether the volumes exists or not.
python script to list pods with pvc in namespace(s): Is a part of a cli to set pods with velero/restic annotations. Hope it helps someone :)
For posterity... There is a Used By: field in the output of describe.
client-go didn't give this api... ,PodPVCIndex can solve the problem
Hi thanks worked for me ;) but I want to make it reverse my workarounds with adding after didn't worked do you have any ideas
$ kubectl describe pvc -A Used" Name: ocs-deviceset-lso-volumeset-0-data-1b45dn Namespace: openshift-storage StorageClass: lso-volumeset Used By: rook-ceph-osd-1--8fwpd Also useful ^
the reason it didn't work is because each return does, in point of fact, have a key defined for claimName. That key is just set to null value. So, what you'd actually want to do is test for nulls. As nice as answer is, it's a PITA to parse unstructured human-readable command output, as opposed to command output in a markup language that well known shell parsers like jq and yq can work with. Towards that end, because I had use of this, I came up with the following: That simple not null test at the end plucks out all your nulls. Obviously invert the last conditional if you want all the nulls, but you'll get all sorts of temp things that way that you probably won't care about.
Code change:
<ins> This file is autogenerated, but we've stopped checking such files into the repository to reduce the need for rebases. Please run hack/generate-docs.sh to populate this file. </ins>

Related discussion:
text: As the RBAC role need to be related to resources. I think we could use a command to get the supported resources. ref to
This would be cool.
I thought we a command that listed resources in the discover doc a long time ago.
is just the versions, but principle is the same. We want to list all the types, their resources, and tie that back to "explain".
What's the best way to determine this information currently? I'm having difficulty figuring out the exact set of permissions (and how they would be written in an RBAC role) for any given kubectl command. The documentation for this right now is split across multiple places and certain things are not explained at all. Specifically, it's difficult to determine which "API verb" is used for which operations. Take as an example. It's unclear if the way to allow this is to use the "proxy" subresource of a pod or service with "get"/"create"/etc. verbs, or to use the "proxy" verb with the resource (pod, service) directly. is a similar case. The almost works for this purpose, but it's still difficult. Operations for a given resource are grouped into categories like write, read, status, and proxy, but these things don't obviously correlate with API verbs. Again, proxy is especially confusing as there is no mention of a proxy "verb". The API operations are only shown using their HTTP verbs. One thing that could help on this document would be a section on the right column under "kubectl command" that shows exactly the rule needed in an RBAC role to allow this command via kubectl. And even then, that assumes an exact 1-to-1 mapping between API endpoints and kubectl commands, which I doubt is always the case. (For example, port fowarding to a pod seems to require both a GET on the pod resource and a CREATE on a port forward subresource.) There also needs to be better documentation about how this information could have been determined in the first place. I've resorted to manually looking through API requests made with but even then it's difficult to figure out. Amusingly, I was the one who wrote which is referenced in the original issue description (as well as the table explaining verbs in ).
Code change:
<ins> This file is autogenerated, but we've stopped checking such files into the repository to reduce the need for rebases. Please run hack/generate-docs.sh to populate this file. </ins>

Related discussion:
text: tl;dr: It's too difficult right now to go from "I want a user to be able to run " to "here is the RBAC rule to use for that" for any case where there isn't a specific example shown in the docs.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
It seem that relative PR stop updated. If this issue still valuable, i will help fix it
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 stale
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
Code change:
// prior to final deletion, we must ensure that finalizers is empty if len(namespace.Spec.Finalizers) != 0 { <del> err = fmt.Errorf("Unable to delete namespace %v because finalizers is not empty %v", namespace.Name, namespace.Spec.Finalizers) </del> <ins> err = fmt.Errorf("Namespace %v termination is in progress, waiting for %v", namespace.Name, namespace.Spec.Finalizers) return nil, err </ins> } return r.Etcd.Delete(ctx, name, nil) }

Related discussion:
text: There is a funny subtle behvaiour in get namespaces, in which if i call more than one time, it seems that the removal from Terminating state is accelarated. It seems this might indicate a bug, or maybe its not a bug and the eventual semantics of is a little funny sometimes. in any case, here's what we are seeing : 1) when i delete a namespace the first time usning kubectl, we get a state change to . that is correct, of course. 2) but ... if make the call a second time, then the same status line is immediately removed from . Expected behaviour : A second call to "kubectl delete ..." shouldn't have any effect on the timing of removal of a namespace from 'Terminating' state*... So i guess there is some "eventual consistency" subtle bug that is resolved by repeated calls to
suggests this may not be e bug, maybe its just the etcd eventual deleter thingy.
Looks to definitely be a bug. The 2nd delete seems to have interrupted the delete process and artifacts (like events) from the namespace still exist in etcd.
investigating...
oops, see the error, will submit a fix.
I have a fix, but need a test case, will submit PR tomorrow AM
Code change:
return plugin.getFakeVolume(&plugin.Detachers), nil } <ins> func (plugin *FakeVolumePlugin) GetDetachers() (Detachers []*FakeVolume) { plugin.RLock() defer plugin.RUnlock() return plugin.Detachers } </ins> func (plugin *FakeVolumePlugin) GetNewDetacherCallCount() int { plugin.RLock() defer plugin.RUnlock()

Related discussion:
text: Looks like similar issue with
That's the PV controller this is the attach controller, thus separate issues.
Code change:
} if test.expectFailure { err = waitForResizingCondition(pvc, m.cs, csiResizingConditionWait) <del> gomega.Expect(err).To(gomega.HaveOccurred(), "unexpected resizing condition on PVC") </del> <ins> framework.ExpectError(err, "unexpected resizing condition on PVC") </ins> return }

Related discussion:
text: What happened: After fixing golint failures under (now still in progress), we need to put for each and . Then common error checking code has become like: We can replace this code with which is more readable and easy to be understood what the code does. Now we have following e2e test directories which can be replaced: [x] test/e2e/apimachinery/ () [x] test/e2e/apps/ () [x] test/e2e/auth/ () [x] test/e2e/common/ () [x] test/e2e/node/ () [x] test/e2e/storage/ () [x] () [x] () [x] () [x] () [x] () [x] () [x] [x] test/e2e/storage/persistentvolumes- [x] () [x] () [x] [x] [x] [x] [x] ()
/sig testing /kind cleanup
/assign PR will be submitted soon.
Fix the following in
Fix in
Fix in
Hi, maybe I could take files beneath test/e2e/storage/vsphere/
oops, I'm finished and prepare for PR.
Thank you That's OK
Fix the following in
/assign
All related PRs were merged. I think this ticket can be closed. BTW, should we also replace to ?
Thanks for your work. thing is managed with We are almost finishing the work also :-)
/remove-kind bug
I found in these files. I'm working on :
I can work to the following item.
Code change:
// TODO: we should consider merge this struct with GroupVersion in unversioned.go type APIVersion struct { // Name of this version (e.g. 'v1'). <del> // +optional </del> Name string `json:"name,omitempty"` }

Related discussion:
text: FYI. Currently the field of TPR is marked as which is wrong, actually if you try to create a TPR with empty versions, it will cause api server panic. Versions should be necessary field of TPR, we should validate this somehow.
Code change:
readinessProbe := &v1.Probe{ Handler:             execHandler([]string{"/bin/cat", "/tmp/health"}), InitialDelaySeconds: 0, <del> PeriodSeconds:       60, </del> <ins> // PeriodSeconds is set to a large value to make sure that the first execution of readiness probe // will happen before the first period passed. PeriodSeconds: 600, </ins> } startupProbe := &v1.Probe{ Handler:             execHandler([]string{"/bin/cat", "/tmp/startup"}),

Related discussion:
text: <!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Seems to be impacting a few KIND jobs on the master branch the most, but also assorted other jobs see the triage link above Reported by Sample failure: /sig node <!-- Please see the deflaking doc () for more guidance! --
xref probing tests
/assign ref /triage accepted
Thanks Elana, still trying today... Does anyone know if we can use the kubelet logs in e2e tests?
Not very portably in cluster e2e tests at least. Maybe in node_e2e instead.
Have you considered that the issue is not with the test but with the underlying code in kubelet like detailed in this issue Like detailed in the issue I can reliably reproduce (on k8s 1.18) the startup probe passing within a few seconds, but the container is only marked as ready after about a minute.
there is already a fix in the 1.21 release for that (part of a bigger PR): And actually this test was to verify that part of the code, but unfortunately sometimes it doesn't respond as quick as it should (but never on my PC, only in ci/cd tests)...
Some recent flakes:
one of the most common flakes in kind jobs currently failures like: Mar 25 17:03:42.508: Pod became ready in 42.007286524s, more than 5s after startupProbe succeeded. It means that the delay readiness probes were not initiated immediately after startup finished.
Maybe we could speed up the review on
Thank you I will take a look. I'm making a pass through flakes tonight trying to identify if anything is on kind's end
I don't think it's kind... since running on my PC with kind it works 100%, I think the issue is either the resources... or contention in the queue as mentioned to in the comment
/milestone v1.22
commented on PR with the suggested fix
/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.
Code change:
readinessProbe := &v1.Probe{ Handler:             execHandler([]string{"/bin/cat", "/tmp/health"}), InitialDelaySeconds: 0, <del> PeriodSeconds:       60, </del> <ins> // PeriodSeconds is set to a large value to make sure that the first execution of readiness probe // will happen before the first period passed. PeriodSeconds: 600, </ins> } startupProbe := &v1.Probe{ Handler:             execHandler([]string{"/bin/cat", "/tmp/startup"}),

Related discussion:
text: </details
Yeah...
Thanks for your great work in keeping things in check
FYI
I have (finally) understood what's happening, and I can even explain why the deflake made things worse... Please have a look at the sleep before the worker starts to process probes: So, you have to remember that we have one worker per pod and per probe, and since we have these probe settings for the test: We have (PeriodSeconds=10) starting sometimes immediately (if the Kubelet has started since more than 10s) or after a quick sleep of rand10s. On the contrary, will likely sleep most of the time for rand60s. This causes a delay in the processing of notifications: If we are lucky, this delay is less than 5s and the test passes: Now you can understand why the deflaked settings were actually worse:
The reason I didn't spot these was that I usually start my cluster once for all and iterate on the tests... so the kubelet had plenty of time to start and I never ended in that sleep.
For the solution, I suggest we either remove the sleep completely, or we find something that would make all 3 probe workers start at the same time to avoid sync issues... For the record, I was able to spot this issue thanks to the following log error (because the channel was overflowing): What do you think ?
I have found another issue in that code: If has already ran (and failed), we go to L245 and don't probe via and therefore wait for the next tick, making the test fail.
This seems consistent with what I found when I was adding e2es for the new probe-level termination grace period and why I did my timing math the way I did.
/reopen I don't think this is fixed, I just hit it again and gubernator is still showing plenty of flakes:
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
how to check the exact commit used for each test?
Code change:
readinessProbe := &v1.Probe{ Handler:             execHandler([]string{"/bin/cat", "/tmp/health"}), InitialDelaySeconds: 0, <del> PeriodSeconds:       60, </del> <ins> // PeriodSeconds is set to a large value to make sure that the first execution of readiness probe // will happen before the first period passed. PeriodSeconds: 600, </ins> } startupProbe := &v1.Probe{ Handler:             execHandler([]string{"/bin/cat", "/tmp/startup"}),

Related discussion:
text: For instance, I am not sure (from the name) that should include my latest fix...
In your PR the fix wasn't there:
you may send cherry-pick to 1.21 for which is using kubelet 1.21, not 1.22.
is using kubelet. Cherry-pick to 1.20 may be needed as well.
I have found this one that failed even with the fix: corresponding to:
I don't know what could explain this atm... but it seems we still have delay propagating container statuses.
In the job artifacts there are multiple places with this info including the clone records/logs, and In testgrid it's a row.
yeah afaict since the tests ran on my PR after your fix was merged into master, it showed the flake was still present :( Prow will always use the latest master when running CI.
Sorry for doubting what you said... I was probably in deny and hoped this annoyance was fixed once for all :(
Plan: we'll see if Clayton's pod lifecycle refactor and/or the jitter refactor for probes affects this.
Clayton's PR jitter refactor
since isn't (likely) coming to 1.22 we could cut off 90% of flakes by increasing to 15s delay:
it seems it fails even after merging so let's continue our discussion on slack
this is not a regression, our suggestion is not block release on it. feel free to remove the milestone
/milestone v1.23
In Kubelet maybe, but in the flakiness of the e2e tests it was. Unfortunately we can't easily explore the current state :/
In the release blocking jobs the frequency is not horrible now, so unblocking is probably fine, it is not as bad as it was. Outside of the release cycle this is still the flakiest test in some jobs, see e.g. where it's the only flake source we have on record currently.
if we end up needing it, we have a timing/period adjustment PR we can take that should help with the flakiness with
Code change:
It("should lookup the Schema by its GroupVersionKind", func() { schema = resources.LookupResource(gvk) Expect(schema).ToNot(BeNil()) <del> }) var deployment *proto.Kind It("should be a Kind", func() { deployment = schema.(*proto.Kind) Expect(deployment).ToNot(BeNil()) </del> <ins> Expect(schema.(*proto.Kind)).ToNot(BeNil()) </ins> }) })

Related discussion:
text: /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
/sig cli
There may have two issues to fix: doesn't support run with assertion must check whether schema is nil first
/assign
/triage accepted
Code change:
// compute the context. Mutation is not allowed. ValidatedPSPAnnotation is used as a hint to gain same speed-up. allowedPod, pspName, validationErrs, err := p.computeSecurityContext(ctx, a, pod, false, pod.ObjectMeta.Annotations[psputil.ValidatedPSPAnnotation]) if err != nil { <del> return admission.NewForbidden(a, err) </del> <ins> return admission.NewForbidden(a, fmt.Errorf("PodSecurityPolicy: %w", err)) </ins> } if apiequality.Semantic.DeepEqual(pod, allowedPod) { key := auditKeyPrefix + "/" + "validate-policy"

Related discussion:
text: What happened: e2e tests detect whether PSP is enabled based on presence of PSP API objects. An addon that proactively includes a PSP in a manifest can trigger that detection and enable PSP-specific e2e tests that should not be run. What you expected to happen: In addition to detecting presence of PSP objects, consider dry-run creating a pod and verifying the annotation indicating the selected PSP policy is , indicating the admission plugin is active. /sig auth /assign
Code change:
// owner: @derekwaynecarr // alpha: v1.20 <ins> // beta: v1.22 </ins> // // Enables kubelet support to size memory backed volumes SizeMemoryBackedVolumes featuregate.Feature = "SizeMemoryBackedVolumes"

Related discussion:
text: When master opens up for , we need to add this back in: /sig node
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
note to self / 1.21 and 1.22 release notes team -- let's make sure the PR body on the original PR is copied over to the new PR. will think that the old release note and documentation has been covered in 1.21, but we will (I will update this comment with link) manually override it to not show up in 1.21 release notes.
Code change:
"net/url" "reflect" "strings" <ins> "sync/atomic" </ins> "testing" "golang.org/x/net/websocket"

Related discussion:
text: There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
Code change:
if !ignoreChangesAndAdditions { // Add any remaining items found only in modified for ; modifiedIndex < len(modifiedSorted); modifiedIndex++ { <del> patch = append(patch, modified[modifiedIndex]) </del> <ins> patch = append(patch, modifiedSorted[modifiedIndex]) </ins> } }

Related discussion:
text: Deployment is defined in a json file with several environment varibles. Deployment is deployed using "kubectl apply -f ". Pods get most of the environment variables defined, but not all. Specifically, the variables defined in the are named: { "name": "DBHOSTS", "value": "10.0.0.1" }, { "name": "SLACKENDPOINT", "value": "ERRORNOT" }, { "name": "LACKENDPOINT", "value": "ERRORNOT" }, { "name": "SLACK", "value": "ERRORNOT" }, { "name": "CKENDPOINT", "value": "ERRORNOT" }, { "name": "ACKENDPOINT", "value": "ERRORNOT" }, { "name": "KENDPOINT", "value": "ERRORNOT" }, { "name": "CASSANDRALOGGINGLEVEL", "value": "ERROR" }, { "name": "ENABLEGETIP", "value": "" } the environment variables that appear in a pod are: ENABLEGETIP CASSANDRALOGGINGLEVEL KENDPOINT ACKENDPOINT CKENDPOINT DBHOSTS That is, ENV variables named "SLACKENDPOINT", "LACKENDPOINT" and "SLACK" never get passed on to the pods.
It also won't accept "randomshit" as an environment varible. When I add that as an environment variable to an existing deployment and run "kubctl apply -f " nothing happens. This is on version v1.2.4 /
Ehh? Can you post a full but minimized yaml that I can run to reproduce it? , drashkov wrote:
We use JSON files, here is the full one. "SLACK_ENDPOINT" does not appear as an environment variable in the pods. Doing "kubectl apply -f " does not create new pods, and does not pass these variables to the pods. If I change the number of replicas and add a new pod, that pod will be created, but won't have that varible.
I am not able to reproduce on GKE at 1.2.4 when exec'ing into one of the Pods and printing the environment. This is the yaml I used - note the image is different: What are the symptoms you are seeing?