jiebi/CodeConvo huggingface dataset:
Change:
} } <del> if diff := cmp.Diff(tt.want, got); diff != "" { </del> <ins> if got.LastTransitionTime.IsZero() && got.Type != "" { t.Errorf("unexpected empty LastTransitionTime in condition") } if diff := cmp.Diff(tt.want, got, cmpopts.IgnoreFields(api.PodCondition{}, "LastTransitionTime")); diff != "" { </ins> t.Errorf("unexpected field errors (-want, +got):n%s", diff) } })

Discussion:
When a scheduling gated pod is ungated, the condition's is consistently null until the pod is scheduled: Pods without a scheduling gate have the same condition but is populated: Submit a pod with a scheduling gate. Observe that after removal of the gate, the pod condition. I uncovered this while using Kueue and the ProvisioningRequest feature. Since this is reproducible with just the scheduling gate, I think k/k is the right project for the issue. <details</details<detailsGCP </details<details</details<details</details<details</details<details</details
/cc
/sig scheduling
When the pod is gated, what's the condition of the Pod? Is it empty?
The gated pod has just this condition. The transition time is also null, but is that expected since it is the first condition?
/triage accepted
The bug is here: It looks like at this point, the ObjectMeta.CreationTimestamp is already populated. We should copy that field.
/assign
Are you still on this, we meet the same problem.
It's been over a month, I assume you might no longer work on this? We encounter the same bug and hope this bug can be fixed as soon as possible(hopefully next release). Since there is no further update on this issue, I am proposing a protential fix on now, can you assign this issue to me and review the code once you are available? Thanks.
/unassign ahaysx /assign royliang
GitHub didn't allow me to assign the following users: royliang. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /unassign ahaysx /assign royliang 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
Sorry I have been on vacation until today. Thanks for the fix
are you still working on this?
I’ve submitted the PR, but it seems lack of reviewer moving this forward.
Change:
target discoveryendpoint.ResourceManager, ) DiscoveryAggregationController { discoveryScheme := runtime.NewScheme() <del> // Register conversion for apidiscovery apidiscoveryv2.SchemeBuilder.Register(apidiscoveryv2conversion.RegisterConversions) </del> utilruntime.Must(apidiscoveryv2.AddToScheme(discoveryScheme)) utilruntime.Must(apidiscoveryv2beta1.AddToScheme(discoveryScheme)) <ins> // Register conversion for apidiscovery utilruntime.Must(apidiscoveryv2conversion.RegisterConversions(discoveryScheme)) </ins> codecs := serializer.NewCodecFactory(discoveryScheme) return &discoveryManager{

Discussion:
Seeing data race flakes in unit tests: Appears to have just been in /sig api-machinery /priority critical-urgent /assign /cc
This code is mutating the package-level schemebuilder: I think it should be adding the conversions to the local scheme instead:
Fixed in (found several instances)
/triage accepted
Change:
dswp.deleteProcessedPod(volumeToMount.PodName) } <ins> // Cleanup orphanded entries from processedPods dswp.pods.Lock() orphanedPods := make([]volumetypes.UniquePodName, 0, len(dswp.pods.processedPods)) for k := range dswp.pods.processedPods { if _, ok := podsFromCache[k]; !ok { orphanedPods = append(orphanedPods, k) } } dswp.pods.Unlock() for _, orphanedPod := range orphanedPods { uid := types.UID(orphanedPod) _, podExists := dswp.podManager.GetPodByUID(uid) if !podExists && dswp.podStateProvider.ShouldPodRuntimeBeRemoved(uid) { dswp.deleteProcessedPod(orphanedPod) } } </ins> podsWithError := dswp.desiredStateOfWorld.GetPodsWithErrors() for _, podName := range podsWithError { if _, podExists := dswp.podManager.GetPodByUID(types.UID(podName)); !podExists {

Discussion:
If a pod is created and then deleted an entry in processedPods map remains forever (sometimes, it's racy). The problem comes from the fact that calls volume_manager asynchronously. If the last call happens after populator cleaned up resources, an entry is to processedPods and will never be seen. An entry in processedPods map must be deleted if pod doesn't exist and pod runtime should removed according to . To verify that the issue really exists I applaied a simple printing resources in map. Here is a reproducer: brand-new fresh k8s cluster with entries in : a pod, check its uid: that this uid is accurately reported: the pod, wait for a few mins, check for again: The entry will be kept forever because kubelet doesn't know anything about this pod anymore: so no more events will ever come to populater for this uid, and the loop in won't find it because it was already deleted from . n/a <details</details<detailsany </details<details</details<details</details<details</details<details</details
/sig storage
/triage accepted
/priority impoerant-soon
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority impoerant-soon 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
/priority important-soon
/assign
PR () fixed this issue. It is ready to merge since Mar 21.
/assign
Change:
"/var/lib/kubelet/pods/some-pod/volumes/kubernetes.io~fc/fc-in-pod2", } for _, path := range mountPaths { <del> refs, _ := mount.GetMountRefs(fm, path) </del> <ins> refs, err := mount.GetMountRefs(fm, path) if err != nil { t.Errorf("couldn't get mountrefs. err: %v", err) } </ins> var globalPDPath string for _, ref := range refs { if strings.Contains(ref, "kubernetes.io/fc") {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Calls to on unsupported platforms do not report any error and potentially misbehave. What you expected to happen: I would expect an error to be reported, that can be consumed by the caller. How to reproduce it (as minimally and precisely as possible): for and were failing on darwin, and no error was being reported. See: & Environment: OS (e.g. from /etc/os-release): I have been testing on osx/darwin, which is not a supported platform.
/sig storage
/assign
Change:
limitations under the License. */ <del> // Package options contains flags and options for initializing an apiserver </del> <ins> // Package options contains flags and options for initializing kube-apiserver </ins> package options import (

Discussion:
Currently as authentication and authorization are both standard config for all clusters, the kubeapiserver insecure http handler is unsecure, which means the cluster is vulnerable to the attack. So it should be deprecated, even removed totally.
/sig api-machinery
I think removing the insecure option is a good idea. Can you send an email the sig-apimachinery mailing list with a proposed timeline? I think this should be like other GA features and have a one year clock.
Sure, I will send it ASAP.
:+1:
Change:
FilenameParam(flags.Filenames...). Flatten(). Do() <ins> checkErr(r.Err()) </ins> patch := cmdutil.GetFlagString(cmd, "patch") if len(flags.Filenames) == 0 && len(patch) == 0 {

Discussion:
I've reported this before.
From a Makefile I get exit status 255.
Just to be clear (sorry for the basic question), are you saying that when the service file is malformed the crash is unhelpful for debugging? Or that creating any/all services using is currently broken?
The YAML file is not malformed. I think there was something perhaps not quite right about firewalls/rules etc. and this caused to crash unhelpfully.
Change:
pod     *v1.Pod mounter mount.Interface plugin  *nfsPlugin <del> volume.MetricsNil </del> <ins> volume.MetricsProvider </ins> } func (nfsVolume *nfs) GetPath() string {

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:
// WaitForPodsRunningReady waits up to timeout to ensure that all pods in // namespace ns are either running and ready, or failed but controlled by a <del> // replication controller. Also, it ensures that at least minPods are running // and ready. It has separate behavior from other 'wait for' pods functions in // that it requires the list of pods on every iteration. This is useful, for </del> <ins> // controller. Also, it ensures that at least minPods are running and // ready. It has separate behavior from other 'wait for' pods functions in // that it requests the list of pods on every iteration. This is useful, for </ins> // example, in cluster startup, because the number of pods increases while // waiting. // If ignoreLabels is not empty, pods matching this selector are ignored and

Discussion:
The logic to account for all pods being ready is incorrectly counting some pods as being controlled by a replication controller. This is causing the 1.3-1.5 upgrade tests to fail. See https://k8s- as an example. Since , the pre-flight checks fail and the rest of the tests never run. I think this was exposed by which changed some things from ReplicationControllers to Deployments. There's a pod being created by a deployment that also matches the selector of a replication controller, and is therefore being incorrectly counted by cc
Change:
o.mapper, _ = f.Object() o.out = os.Stdout _, pods := createPods(false) <del> pendingPods, err := o.waitForDelete(pods, test.interval, test.timeout, test.getPodFn) </del> <ins> pendingPods, err := o.waitForDelete(pods, test.interval, test.timeout, false, test.getPodFn) </ins> if test.expectError { if err == nil {

Discussion:
In writing some documentation for I noticed some issues with the implementation. I think the simplest user experience is that the command doesn't return until all the user pods are drained off the machine. In particular this means wait until all graceful termination is finished infinitely retry evictions that are rejected due to insufficient PodDisruptionBudget The current implementation does not do this, in particular wait for graceful termination appears to be at 10 sec number of pods, which may be much shorter than the max graceful termination we only retry evictions number of times My suggestion is to change the behavior so that we compute how long to wait for graceful termination, by taking max(grace periods of all pods that we want to delete) (or the value of --grace-period command line argument instead, if that is specified), and wait exactly that amount of time plus a small buffer we retry evictions infinitely WDYT? I think we should do this in 1.5 because the current behavior is very non-obvious.
The problem here is how long should we wait, if the user doesn't specify a timeout. The default timeout used in drain is following how long the reapers have in , , and . Maybe this is not long enough. I can make the changes. Do we still need exponential back off?
To summarize discussion with there are two possible approaches (pseudocode below) 1) Goroutine approach: For each pod P that meets the , do the following: 2) Non-goroutine approach: where "not timed out yet" means you haven't finished waiting max(--grace period argument to kubectl drain, max graceful termination spec across all pods on the node)
Could you please triage this for 1.5 and apply blocker or non-blocker labels as appropriate along with priority.
The PR for this issue is waiting to be merged.
marking this as a release blocker due to being marked as such. Please update if needed cc:
Change:
Opts:   []string{"rw", "relatime", "pagesize=2M"}, }, { <ins> Device: "/dev/hugepages", Type:   "hugetlbfs", Path:   "/mnt/hugepages-2Mi", Opts:   []string{"rw", "relatime", "pagesize=2Mi"}, }, { </ins> Device: "sysfs", Type:   "sysfs", Path:   "/sys",

Discussion:
What happened: Pods get stuck in terminating state, as kubelet failed to unmount volume: nodev on /var/lib/kubelet/pods/-120c-45c4-aeac- type hugetlbfs (rw,relatime,pagesize=2Mi) What you expected to happen: Pod to get deleted and volumes to be cleaned up. How to reproduce it (as minimally and precisely as possible): kvm based virtual machines on ubuntu 16.04. create a pod with hugepage volumes () Delete the pod. Anything else we need to know?: Changes are related to mentioned commit id: In this file : , line no 72 : pageSize, err := resource.ParseQuantity(strings.TrimPrefix(opt, prefix) + "i") The mount already has a pagesize 2Mi in my case as shown here : (rw,relatime,pagesize=2Mi) But the code here suffix/appends "i" assuming pagesize can be only of type 2M or 1024M resulting in failure to clean up this volume. Documentation from code: / NOTE: Adding suffix 'i' as result should be comparable with a medium size. // pagesize mount option is specified without a suffix, // e.g. pagesize=2M or pagesize=1024M for x86 CPUs pageSize, err := resource.ParseQuantity(strings.TrimPrefix(opt, prefix) + "i") if err != nil { return nil, fmt.Errorf("error getting page size from '%s' mount option: %v", opt, err) } when the pod is deployed, kubelet creates the mount and we can see from logs that it already has pagesize=2Mi for my environment.

Environment: Kubernetes version: kubectl version Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-04-16T11:48:36Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Kvm hypervisor based virual machine setupOS (e.g: ): NAME="Ubuntu" VERSION="16.04.6 LTS (Xenial Xerus)" ID=ubuntu IDLIKE=debian PRETTYNAME="Ubuntu 16.04.6 LTS" VERSIONID="16.04" HOMEURL="" SUPPORTURL="" BUGREPORTURL="" VERSIONCODENAME=xenial UBUNTUCODENAME=xenial Kernel (e.g. ): Linux master 4.4.0-169-generic -Ubuntu SMP Tue Nov 12 10:38:00 UTC 2019 x8664 x8664 x8664 GNU/LinuxInstall tools: Network plugin and version (if this is a network-related bug): Others:
/assign bart0sh
/sig storage
What about this change ?
The change looks good to me. Would you be willing to submit a PR?
& : Thanks for the quick turnaround.
We are seeing this issue in 1.18.6 version, can you please push the fix to this branch as well.
Could we know when the problem was introduced? As I suppose we don't have the same issue with K8S 1.17.x release?
Hi same issue found in 1.18.2
It is not yet ported into v1.18.6 as well.
Can you submit your PR for release-1.18 branch?
Change:
NegotiatedSerializer: resource.UnstructuredPlusDefaultContentConfig().NegotiatedSerializer, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { switch p, m := req.URL.Path, req.Method; { <del> case strings.HasPrefix(p, pathCM) && m != "GET": pod := ioutil.NopCloser(bytes.NewReader(cmBytes)) return &http.Response{StatusCode: 200, Header: cmdtesting.DefaultHeader(), Body: pod}, nil case strings.HasPrefix(p, pathCM) && m != "PATCH": pod := ioutil.NopCloser(bytes.NewReader(cmBytes)) return &http.Response{StatusCode: 200, Header: cmdtesting.DefaultHeader(), Body: pod}, nil </del> <ins> case strings.HasPrefix(p, pathCM) && m == "GET": fallthrough case strings.HasPrefix(p, pathCM) && m == "PATCH": var body io.ReadCloser switch p { case pathCM + "/test0": body = ioutil.NopCloser(bytes.NewReader(configMapList[0])) case pathCM + "/test1": body = ioutil.NopCloser(bytes.NewReader(configMapList[1])) default: t.Errorf("unexpected request to %s", p) } return &http.Response{StatusCode: 200, Header: cmdtesting.DefaultHeader(), Body: body}, nil </ins> default: t.Fatalf("unexpected request: %#vn%#v", req.URL, req) return nil, nil

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 bug What happened: The dry run output listed all the resources that would be configured: deployments, HPAs, services, and an ingress: This was expected. However, it then listed all resources again (except for the HPAs) as being pruned: The config was then applied with: As expected, no resources were actually pruned. What you expected to happen: should actually display which resources are going to be pruned. How to reproduce it (as minimally and precisely as possible): a YAML file to with it: run + prune: should be listed as both configured and pruned it again with pruning: that the deployment is configured but not pruned, even though the dry run said it would be. Anything else we need to know?: Was trying to write a devops script that gave a warning before any resources would be pruned. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): (Lubuntu 18.04) Kernel (e.g. ):Install tools: Others:
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 can reproduce it, and i will try to fix it.
Change:
ginkgo.By("Creating statefulset") statefulset := e2estatefulset.CreateStatefulSet(client, manifestPath, namespace) <ins> defer e2estatefulset.DeleteAllStatefulSets(client, namespace) </ins> replicas := *(statefulset.Spec.Replicas) // Waiting for pods status to be Ready e2estatefulset.WaitForStatusReadyReplicas(client, statefulset, replicas)

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: The following issues are observed while running this e2e test case for vSphere CSI Migration feature validation. Issue-1 - test failed with Unexpected error: This is happening because YAML is using version. Issue-2 - After upgrading from . Test executed successfully but reported failure in the cleanup stage. when is called in DeleteAllStatefulSets, it does not find statefulset. moving call to in the defer block helps avoid printing this message. There may be a race between namespace deletion and after each execution. I am not familiar with recent e2e framework changes. What you expected to happen: Test should pass. How to reproduce it (as minimally and precisely as possible): execute using Kubernetes master branch builds. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere Cloud Provider
/sig testing /sig storage
/remove-sig testing The framework and CI are SIG testing. SIG storage owns their 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. 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
Change:
inkscape:cx="306.01712" inkscape:cy="-127.6824" inkscape:document-units="px" <del> inkscape:current-layer="layer1" </del> <ins> inkscape:current-layer="text4373" </ins> showgrid="false" inkscape:window-width="1519" inkscape:window-height="822"

Discussion:
The logo (, ) font does not match the others. I believe the png/pdf versions are correct.
What other ones? It should be the same font - they look the same to me...