jiebi/CodeConvo huggingface dataset:
Change:
podsGetter     corev1lister.PodLister nodesGetter    corev1lister.NodeLister <del> expansionRecoveryEnabled              bool dynamicResourceAllocationEnabled      bool kubeletCSRAdmissionValidationDisabled bool </del> <ins> expansionRecoveryEnabled                       bool dynamicResourceAllocationEnabled               bool allowInsecureKubeletCertificateSigningRequests bool </ins> } var (

Discussion:
This comes from We've a feature gate, . However, we try to name feature gates after the positive thing they add, even if it's on by default, or even if we're setting if false because the positive thing is being dropped (rare, but it happens). Typically we don't start feature gate names with , as it makes the docs jar: Example quote 1: To temporarily revert to the legacy behavior, enable the feature gate. vs Example quote 2: You can enable the feature gate if you run code that relies on the previous behavior. You should plan to migrate. and because disabling things isn't really a feature. Some examples of gates you can or once could disable by turning them off_ include: - - - So, I recommend a rename of the gate before the v1.31 release. /sig auth architecture
FYI
Example gate names: (off by default) (off by default) (on by default) (on by default) (on by default) from (off by default, deprecated)
/milestone v1.31
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.31 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
Another possibility: , deprecated, off by default
Hello there! I am new to kubernetes and I want to contribute in it. Is it something that I can contribute to?
This issue is not a good issue for a first-time contributor to work on.
I'm a fan of , deprecated, off by default
hoping one of you are doing the PR? :) /milestone v1.31
Change:
testSlowMultiplier = 60 ) <del> var _ = SIGDescribe("Device Plugin", func() { </del> <ins> var _ = SIGDescribe("[Feature:GPUDevicePlugin] Device Plugin", func() { </ins> f := framework.NewDefaultFramework("device-plugin") var cs clientset.Interface

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Flakes on: Passed on: N/A See above. The test requires hosts with GPUs attached, which is not common in a CI. The test shouldn't be run automatically with every other labeled test, it should have a dedicated, specific label which should be excluded in most jobs. At the very least, it should have the, which is a Windows image (not Windows servercore image), which is ~10-11 GB in size, so it can take some time to download. Additionally, in some cases, the test lingers for hours, which is problematic: This can be observed here: Worth noting that the test has been explicitly skipped in a few test runs: /sig windows /sig testing /cc /cc /cc /cc
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
similar to disabled it for some tests in Looks like we missed disabling it from those tests above
Change:
} return &REST{store}, nil } <ins> // Implement CategoriesProvider var _ rest.CategoriesProvider = &REST{} // Categories implements the CategoriesProvider interface. Returns a list of categories a resource is part of. func (r *REST) Categories() []string { return []string{"api-extensions"} } </ins>

Discussion:
What would you like to be : Adding a "webhooks" group to kubectl to show mutating/validating webhooks would be super useful Why is this needed: There are a few reasons this is useful (to me): often cannot remember the right names for these resources, are very long and I often have a typo often want to enumerate all of them on the system. cc
/sig cli
I think this is a great idea, definitely something I could've used in the past. I'd be interested in taking a pass at implementing this if the proposal gets accepted.
Instead of building a category based on the types we have, I would build the category based on why people look at them. I suspect a category like which returned admission config admission config for various CSI types to list in CRD would be very helpful.
Webhook is far too generic. By putting admission webhooks in there we basically steal that word from the ecosystem to be used for other purposes. "admissionwebhooks" I could agree with.
Yeah, there are other webhooks, e.g. CRD conversion webhooks or authz webhooks...
I'd expect the short names "mwc" and "vwc" to be set up, are they not?
Unfortunately, they are not.
/triage accepted /assign
does category tolerate namespacing? i.e. would be tolerated? Still a bit long, but shorter than
It's a string, so you could theoretically namespace that.
Change:
"node-y": false, }, }, <ins> { name: "terminating Pods should be excluded", pod: st.MakePod().Name("p").Label("foo", "").SpreadConstraint( 1, "node", hardSpread, st.MakeLabelSelector().Exists("foo").Obj(), ).Obj(), nodes: []*v1.Node{ st.MakeNode().Name("node-a").Label("node", "node-a").Obj(), st.MakeNode().Name("node-b").Label("node", "node-b").Obj(), }, existingPods: []*v1.Pod{ st.MakePod().Name("p-a").Node("node-a").Label("foo", "").Terminating().Obj(), st.MakePod().Name("p-b").Node("node-b").Label("foo", "").Obj(), }, fits: map[string]bool{ "node-a": true, "node-b": false, }, }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {

Discussion:
How to reproduce it (as minimally and precisely as possible): pre-requisites: a multi-az cluster, a deployment with 1 pod in each az. a with and . the node(s) in 1 az. the deployment's pod(s) from the cordoned az. What happened: A new pod was created and scheduled in a form that What you expected to happen: I expected that a new pod will be created and be "stuck" in status as it shouldn't have nowhere be scheduled. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ): 4.19.84-coreos Others: I created a with how I reproduce the bug
/sig scheduling
cc/
Thanks for raising this issue. I feel like it's a general timing issue - when you delete a Pod, that Pod may still exist for a very short time (in graceful deletion period), and at the same time, the controller backfills a Pod for it. So when scheduling tries to schedule the backfill Pod, it may read the cluster as: [1, 1, 1(deleting)]. To confirm this, can you try deleting the Pod using , and see if the problem goes away?
Yes sure I will try that. It sounds reasonable, thats why in the first demonstration I deleted all the pods and waited for all of them to completely disappear. Nevertheless, this is still something that I believe needs to be fixed. The pod's evaluation should take in consideration pods that are in status and don't count them as pods.
I do believe we exclude the Pods. (if not, it should be a serious regression). What concerns me is that at that moment, scheduler may treats that (deleting) Pod as running in its cache. I will try to debug into this.
Yep, this time the new pod was in status until I uncordoned the relevant nodes.
Change:
// the list automatically by PodDisruptionBudget controller after some time. // If everything goes smooth this map should be empty for the most of the time. // Large number of entries in the map may indicate problems with pod deletions. <ins> // +optional </ins> map<string, k8s.io.apimachinery.pkg.apis.meta.v1.Time> disruptedPods = 2; // Number of pod disruptions that are currently allowed.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: PodDisruptionBudget provides inappropriate message and cannot be updated as is required filed. What you expected to happen: works fine for editing labels under . Also, produce correct error message when edit field. How to reproduce it (as minimally and precisely as possible): Then, we will get following error after step-2. When edit , it should provide correct message as .When edit especially labels under metadata, they should be updated without error. Anything else we need to know?: According to the code comment, is valid. Environment: Kubernetes version (use ): build on
/sig cli
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 there is a PR open
Change:
ibytes = -1 } if err = setQuotaOnDir(path, id, ibytes); err == nil { <del> quotaPodMap[id] = volumeuid </del> <ins> quotaPodMap[id] = internalPodUid </ins> quotaSizeMap[id] = ibytes <del> podQuotaMap[volumeuid] = id </del> <ins> podQuotaMap[internalPodUid] = id </ins> dirQuotaMap[path] = id <del> dirPodMap[path] = volumeuid podDirCountMap[volumeuid]++ </del> <ins> dirPodMap[path] = internalPodUid podUidMap[internalPodUid] = externalPodUid podDirCountMap[internalPodUid]++ </ins> klog.V(4).Infof("Assigning quota ID %d (%d) to %s", id, ibytes, path) return nil }

Discussion:
I have kubernetes 1.24.7. I tried to use on formated volume. It works until first reboot. After reboot, I get messages: I expect that project quota can be assigned even after reboot. Use xfs for /var/lib/containerd with discard,quota,prjquota No response <details</details<detailsbaremetal </details<details</details<details</details<detailsrke2 </details<details</details
/sig node Can this be reproduced? Can this pod be recreated correctly if you force delete the pod?
/triage accepted
It can be reproduced. Pod is created if I remove . I can test force delete.
/assign we are looking into gate to understand if we need to keep it or deprecate it.
If I force delete pod, it does not start again:
/assign Let me check on the latest code with the fix
Change:
if kubeDeps.KubeClient != nil { glog.Infof("Watching apiserver") <ins> if updatechannel == nil { updatechannel = cfg.Channel(kubetypes.ApiserverSource) } </ins> config.NewSourceApiserver(kubeDeps.KubeClient, nodeName, updatechannel) } return cfg, nil

Discussion:
/kind bug cc. What happened: Since - specifically , kubelet always calls , leading it to always register an apiserver source with the . This leads to to never return true in cases where the kubelet is not configured to communicate with an apiserver. The direct result of this is that when removing a manifest from the directory, kubelet never kills the containers. What you expected to happen: The containers get killed properly. How to reproduce it (as minimally and precisely as possible): Configure kubelet standalone without an apiserver, and with a static pod manifest path. Add a manifest, then remove it. Observe the containers stick around. Set logging to greater than level 6, and see a lot of . Environment: Kubernetes version (use ): 1.9.2 (1.8.7 works)
- Is there a run a static manifest that's not a master test case in the node-e2e suite?
I don't think there are standalone kubelet tests since it's hard to observe the pod status.
Change:
REGISTRY ?= staging-k8s.gcr.io IMAGE = $(REGISTRY)/pause <del> TAG = 3.5 </del> <ins> TAG = 3.6 </ins> REV = $(shell git describe --contains --always --match='v*') # Architectures supported: amd64, arm, arm64, ppc64le and s390x

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 --When including windows in a pause build I get a rate limit error as it tries to pull dockcross/windows-static-x64:latest. This causes the build to fail. This image should be stored and pulled from as there should be a copy of this in to mimic kube-cross for Linux images cd build/pause make all-push Kubernetes version : v1.20.1 Cloud provider or hardware configuration: N/A OS (e.g: ): Build running on Linux (includes cross compiling for windows) Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 windows
Are you either of you able help with getting this image into the k8s gcr or if there is a reason why it can't be put there??
context - this might be due to use pulling from a small # of vmware VIPs
goal from sig-windows ~ move this into GCR eventually ~ would that be ok ?
do you know any history for this image?
That image carried over from the original work from . I have asked sig-testing previously if we could include that image's functionality into ` into the image. I can try this out in the morning, and if it works, I can send some PRs.
Seems to work. I have sent 2 PRs for this:
Change:
// Test 2: re-create a LB of a different tier for the updated Service. ginkgo.By("updating the Service to use the premium (default) tier") svc, err = jig.UpdateService(func(svc *v1.Service) { <del> clearNetworkTier(svc) </del> <ins> setNetworkTier(svc, string(gcecloud.NetworkTierAnnotationPremium)) </ins> }) framework.ExpectNoError(err) // Verify that service has been updated properly.

Discussion:
ci-kubernetes-e2e-gci-gce-coredns ci-kubernetes-e2e-gci-gce-slow ci-kubernetes-e2e-gci-gce-ipvs Basically, all jobs that run the test :) [sig-network] Services [Slow] should be able to create and tear down a standard-tier load balancer 06-05
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 network it seems you reported failures in this test previously and seems a GCE feature dependent on the GCE controller, can you PTAL? cc
It has been so long that I entirely forgot what was the previous cause. From a quick look, the gce loadbalancer controller stuck on an address not found error (logs from ):
Full logs related to the problematic service : It reads like the controller thought the service desired tier network, where it actually wanted ? Would it be (purely based on the timing - don't see how that is related yet)
/assign Thanks It is indeed caused by . Pushed a PR to fix the e2e test.
Change:
// and get cached node info by given node name. nodeInfoCopy := f.cachedNodeNameToInfo[node.GetName()].Clone() <del> potentialVictims := util.SortableList{CompFunc: util.HigherPriorityPod} </del> <ins> potentialVictims := util.SortableList{CompFunc: util.MoreImportantPod} </ins> removePod := func(rp *v1.Pod) { nodeInfoCopy.RemovePod(rp)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When selecting victims on node in (), take pod's into account. When two pod's Priority is equal, preempt pod whose is later first. Why is this needed: If a pod's has been running for a longer time, it might finish earlier, or it might have done more things. It might make more sense to preempt them later, e.g. a user submitted a job A at time 9:00 am, then he submitted a job B at time 10:00 am, he might expect that scheduler preempts pods for job B first. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/sig scheduling /assign cc
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
/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
/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
PR implements this feature. We are currently in code freeze for 1.14. The feature will be in 1.15.
Thanks for it. It is similar with a little difference, the PR aims to select a node, and this issue aims to pick a pod whose StartTime is latter after the node has been selected.
I just sent a PR for it. PTAL :)
Change:
package cni import ( <ins> "errors" </ins> "fmt" "sort" <ins> "sync" "time" </ins> "github.com/appc/cni/libcni" cnitypes "github.com/appc/cni/pkg/types"

Discussion:
Host network pods should be able to be created before the container network exists. Pod syncs for pods on the container network should fail until the container network is configured. cc
ref:
I think this is a thing we should make working before v1.4, so adding the milestone. Complain if you disagree. Also, does volunteer to make a PR? :)
Going to make a first pass at this in
Great!
/cc
Change:
REGISTRY?=gcr.io/google_containers ARCH?=amd64 TEMP_DIR:=$(shell mktemp -d -t hyperkubeXXXXXX) <del> CNI_RELEASE=07a8a28637e97b22eb8dfe710eeae1344f69d16e </del> <ins> CNI_RELEASE=0799f5732f2a11b329d9e3d51b9c8f2e3759f2ff </ins> CACHEBUST?=1 QEMUVERSION=v2.7.0

Discussion:
Started as a tangent of Many CNI plugins don't properly handle a action on missing resources. The spec says, , however many improperly return an error. I see the steps moving forward to be: [x] Modify CNI plugins bundled with Kubernetes to properly support del (flannel already done; bridge, ipvlan, macvlan, and ptp in containernetworking/cni) [x] Create release of containernetworking/cni Does this make sense? cc/
SGTM - I'm working on the right now and can do the CNI release too. On the 3rd check box - why is that still a thing? Doesn't the CNI project provide the required artifacts as part of its release? Maybe not something to resolve now but I'd like to make sure the CNI project is providing the right things to projects that use it.
I just want to say thanks to everyone for jumping on this.
status tracking doc
I can test out patches as needed. I currently only have test cases for Weave and Calico, but it should not be too difficult to add others.
It would be great to get flannel tested too. You probably need a master build of the flannel CNI plugin and possibly some flannel patches to be merged. Feel free to DM on slack if you need more info.
s390x builds are missing still. If that's , we can switch to v0.5.1 in time for v1.7. However, I really don't want to bump from v0.3.0-ish to v0.5.0 one day before release. This is a v1.7 issue to ensure all CNI plugins (including the official) work as intended with Kubernetes and an issue to make sure we update to CNI v0.5.0 w/ spec v0.3.0 in time for v1.7. I think will solve the short-term solutions. Also it seems like Weave, Calico and maybe Canal has fixed this as-is. I think Flannel works with
I'm a little confused! You mean s390x builds for flanneld? And what do you mean by This is a v1.7 issue I thought this was a 1.6 issue?

CNI still needs s390x binaries to be consumable by k8s: Two other conclusions: 1) We should go with as the immediate solution 2) We should upgrade to CNI v0.5.1 (when released( officially for Kubernetes in time for v1.7 and enforce the latest spec (v0.3.0) for all network plugins
We should get the PR in (after testing), but this is not a really solution as it only avoids hitting this problem at cluster setup.
OK, that makes sense on the s390x binaries. I've just released v0.5.1 of CNI, which updates the plugins with the new del behaviour. They should all still be back compatible with the older spec versions so I recommend that K8s takes this CNI release.
I'm working on a patch for that bump now
Be aware that has just been merged. If you sync to HEAD, you won't be able to reproduce this problem at cluster setup easily.
New cni packaged tarball (based on v0.5.1) has been pushed:
-- can this be closed?
we can't close until all the consumers have been updated to point to the new tarballs
What is the ETA for resolving this?
Ok, I see that is at the top of the submit queue.
Change:
} for _, tc := range cases { <del> source := makeProjection("", tc.mode, "downwardAPI") source.Sources[0].DownwardAPI.Items = tc.volumeFile client := fake.NewSimpleClientset(tc.pod) _, host := newTestHost(t, client) var myVolumeMounter = projectedVolumeMounter{ projectedVolume: &projectedVolume{ sources: source.Sources, podUID:  tc.pod.UID, plugin: &projectedPlugin{ host: host, </del> <ins> t.Run(tc.name, func(t *testing.T) { source := makeProjection("", tc.mode, "downwardAPI") source.Sources[0].DownwardAPI.Items = tc.volumeFile client := fake.NewSimpleClientset(tc.pod) tempDir, host := newTestHost(t, client) defer os.RemoveAll(tempDir) var myVolumeMounter = projectedVolumeMounter{ projectedVolume: &projectedVolume{ sources: source.Sources, podUID:  tc.pod.UID, plugin: &projectedPlugin{ host: host, }, </ins> }, <del> }, source: *source, pod:    tc.pod, } </del> <ins> source: *source, pod:    tc.pod, } actualPayload, err := myVolumeMounter.collectData() if err != nil && tc.success { t.Errorf("%v: unexpected failure making payload: %v", tc.name, err) return } if err == nil && !tc.success { t.Errorf("%v: unexpected success making payload", tc.name) return } if !tc.success { return } if e, a := tc.payload, actualPayload; !reflect.DeepEqual(e, a) { t.Errorf("%v: expected and actual payload do not match", tc.name) } }) </ins> <del> actualPayload, err := myVolumeMounter.collectData() if err != nil && tc.success { t.Errorf("%v: unexpected failure making payload: %v", tc.name, err) continue } if err == nil && !tc.success { t.Errorf("%v: unexpected success making payload", tc.name) continue } if !tc.success { continue } if e, a := tc.payload, actualPayload; !reflect.DeepEqual(e, a) { t.Errorf("%v: expected and actual payload do not match", tc.name) } </del> } }

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: I run the unit tests for , but I found it would not clean the tempdir it created. ! What you expected to happen: automatically clean up when finishing unit tests. How to reproduce it (as minimally and precisely as possible): go test $ Anything else we need to know?: Environment: k8s 1.15 Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage /sig testing
/assign Assign the issue to you since you have fired a pull request.