jiebi/CodeConvo huggingface dataset:
Change:
sort.Sort(l) } <del> // HigherPriorityPod return true when priority of the first pod is higher than // the second one. It takes arguments of the type "interface{}" to be used with // SortableList, but expects those arguments to be *v1.Pod. func HigherPriorityPod(pod1, pod2 interface{}) bool { return GetPodPriority(pod1.(*v1.Pod)) > GetPodPriority(pod2.(*v1.Pod)) </del> <ins> // MoreImportantPod return true when priority of the first pod is higher than // the second one. If two pods' priorities are equal, compare their StartTime. // It takes arguments of the type "interface{}" to be used with SortableList, // but expects those arguments to be *v1.Pod. func MoreImportantPod(pod1, pod2 interface{}) bool { p1 := GetPodPriority(pod1.(*v1.Pod)) p2 := GetPodPriority(pod2.(*v1.Pod)) if p1 != p2 { return p1 > p2 } return GetPodStartTime(pod1.(*v1.Pod)).Before(GetPodStartTime(pod2.(*v1.Pod))) </ins> }

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:
return fmt.Errorf("nil %q node object", kl.nodeName) } <del> kl.updatePodCIDR(node.Spec.PodCIDR) </del> <ins> if node.Spec.PodCIDR != "" { kl.updatePodCIDR(node.Spec.PodCIDR) } </ins> kl.setNodeStatus(node) // Patch the current status on the API server

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In my test setup I allocate POD CIDRs manually, bridge is configured before starts. Important settings: on example node: on master: Then I see confusing entries in logs (): Fortunately everything keeps working, thanks to this condition: , i.e. it is not propagated to CNI plugin. It appears that this very line tries to set the CIDR to whatever the master returns during node status update: What you expected to happen: / use the pod CIDR given at command line and never mess with it Actually I'm a bit confused if manual per-node pod CIDR assignment is supported at all, and if I'm doing it correctly. I'm aware it's unusual thing to do in production environment, yet for testing it seems perfectly legitimate. Environment: Kubernetes version (use ): v1.10.0 Cloud provider or hardware configuration: bare metal OS (e.g. from /etc/os-release): Ubuntu 17.10 Kernel (e.g. ): Install tools:
/sig network
Kubelet need to make a check of CIDR before
/assign
Change:
glog.V(2).Infof("SyncLoop (PLEG): %q, event: %#v", format.Pod(pod), e) handler.HandlePodSyncs([]*api.Pod{pod}) } if e.Type == pleg.ContainerDied { <del> if podStatus, err := kl.podCache.Get(e.ID); err == nil { if containerID, ok := e.Data.(string); ok { kl.containerDeletor.deleteContainersInPod(containerID, podStatus) } </del> <ins> if containerID, ok := e.Data.(string); ok { kl.cleanUpContainersInPod(e.ID, containerID) </ins> } } case <-syncCh:

Discussion:
Kubelet evicts pods whenever there is memory or disk pressure. It marks the pods as to evict them. To help with reducing disk pressure, kubelet should delete all containers belonging to pods right away. This will result in loss of logs. In the future, we can copy out logs from dead containers before deleting them. Logs can be rotated separately from dead containers. IMO, this feature is required for disk usage based evictions to work reliably in kubelet.
Change:
} } <ins> crdSpec := &spec.Swagger{} </ins> for _, s := range crdSpecs { <del> mergeSpec(&specToReturn, s) </del> <ins> // merge specs without checking conflicts, since the naming controller prevents // conflicts between user-defined CRDs mergeSpec(crdSpec, s) </ins> } <del> return &specToReturn </del> <ins> // The static spec has the highest priority. Resolve conflicts to prevent user-defined // CRDs potentially overlapping the built-in apiextensions API if err := aggregator.MergeSpecsIgnorePathConflict(&specToReturn, crdSpec); err != nil { return nil, err } return &specToReturn, nil </ins> } // mergeSpec copies paths and definitions from source to dest, mutating dest, but not source.

Discussion:
What happened: Created a CRD with a group/version/kind that defines a CustomResourceDefinition type overlapping with the in-tree kubernetes type (WARNING: do not create this CRD on a cluster you care about, see ) Note that two definitions for the group/version/kind appear in openapi: What you expected to happen: published openapi only includes the in-tree type, which has precedence /cc /area custom-resources /priority important-soon /sig api-machinery
/cc
haven't looked into the code yet. I'd expect the naming controller / apiextensions server to prevent conflicting CR GVK, but they are unaware of builtin API groups
CRD handling is isolated to the apiextensions server... it does not have information about all other built-in and aggregated APIs
mentioned something he was working on to make the aggregation layer honor APIService priorities (so that later definitions would not be included if something had already defined a GVK) edit: possibly
a naive idea is to reserve k8s groups in a hard code way that sounds good the CRD in defines a but the kubectl results are about . Did I miss something?
oops... fixed. I started with an API type under but the issue only surfaces for specific APIs (due to the generated definition name colliding for some types)
that wouldn't address duplicate GVKs from aggregated APIs
Three kinds of openapi paths/definitions that we want to prevent CRDs from overwriting: CRD API the spec aggregation in apiextensions-apiserver allows overwriting. I will send a fix native APIs well protected. The spec aggregation in kube-aggregator: 1) ignores duplicated paths and renames duplicated definitions; 2) treats kube-apiserver with than apiextensions-apiserver APIs the spec aggregation in kube-aggregator allows overwriting. The spec aggregation in kube-aggregator treats aggregated APIs with than apiextensions-apiserver. I'm thinking about giving apiextensions-apiserver the lowest priority, but then the problem is aggregated APIs can potentially overwrite the CRD API Note that none of the above prevents CRDs from adding new subpaths to existing APIs. E.g. a CRD can add a path to the CRD API, or to a aggregated API if it didn't have one
Change:
"k8s.io/klog" "k8s.io/kubernetes/pkg/api/legacyscheme" "k8s.io/kubernetes/pkg/scheduler" <ins> // import DefaultProvider _ "k8s.io/kubernetes/pkg/scheduler/algorithmprovider/defaults" </ins> schedulerapi "k8s.io/kubernetes/pkg/scheduler/api" "k8s.io/kubernetes/pkg/scheduler/factory" "k8s.io/kubernetes/test/integration/framework"

Discussion:
What happened: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Maybe this error is introduced in by one commit (I haven't yet found it). And we need init DefaultProvider when we setup Scheduler in . /sig scheduling /kind bug /assign /cc
This is an interesting issue! I also see it on my machine, but as you pointed out, there is no recent change that could possibly cause this. In fact, we were in code freeze and no PR got merged into the schedule code base in the past ~couple of weeks. I wonder if a change in our build tools are made recently that introduced this.
Change:
if err != nil { return "", err } <ins> // make podIPs order match node IP family preference #97979 podIPs = kl.sortPodIPs(podIPs) if len(podIPs) > 0 { podIP = podIPs[0] } </ins> switch internalFieldPath { case "spec.nodeName": return pod.Spec.NodeName, nil

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 --In a dual-stack cluster with IPv4 as default family (first kubelet IP), a container is created with a env var set to . When the container is running, properly contains the IPv4 But at runtime, this env var (used in container args) is expanded to the pod IPv6 instead of the IPv4. When using , it should always return the value actually exposed as and not something else. Kubernetes version:Cloud provider or hardware configuration: Bare metal cluster OS (e.g: ): Ubuntu 20.04 Kernel (e.g. ): Linux 5.8.0-59-generic 66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x8664 x8664 x86_64 GNU/Linux Network plugin and version (if this is a network-related bug): cilium 1.10 Others: CRI-O 1.21 + crun.
Note: I have a configuration that matches the ones that had IP ordering issue before was fixed. So it may be related.
/sig network
Just a guess, but I wonder if it may be caused by
That's it. The fix from properly sort IP when computing the Pod status, but the sorted IPs are then replaced by computed IPs as this log shows.
/triage accepted Thanks for the detailed report
/assign
Change:
func main() { flag.Parse() <ins> rand.Seed(time.Now().UTC().UnixNano()) </ins> // Set up logger for etcd client etcd.SetLogger(log.New(os.Stderr, "etcd ", log.LstdFlags))

Discussion:
In Kubernetes 1.26, Kubernetes Enhancement Proposal, KEP-3352[1]: Aggregated Discovery, enhanced the discovery mechanism and supported aggregated discovery optimizing response for discovery api. To support this KEP, Changes were made to both API server and client to support aggregated discovery mechanism. This feature was available alpha in Kubernetes 1.26 behind a feature flag, . In Kubernetes 1.27, aggregated discovery endpoint was promoted to beta and enabled by default[2]. Here is a class of problems that ended up getting triggered. GOOD NEWS!! is that it is already fixed by in 1.27 and a cherry pick in 1.26 For example, With Prometheus adapter, we saw issues across repositories: One signature of this is following in the traceback:
Searching for that method signature: Currently shows the following:
Leaving this open for some time, just to serve as a point of coordination if needed. The advice/guidance here is for folks to update to newer versions of 1.26/1.27 client-go.
/sig api-machinery
Components that do generate custom metrics (grepping through sources!): etc..
Thanks, Any custom server, sending nil GVK could trigger this bug. So far have seen it through custom metrics via promethus-adapter.
Thanks for tracking this /cc /triage accepted
For those searching in the future, the impacted versions are: 26.0 - 0.26.3 The fixed versions are: 26.4+ As well as updating , make sure that your other dependencies do not pull in any of the affected versions.
/close i think that's about it for now..
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
Change:
pod. release: v1.19 file: test/e2e/scheduling/preemption.go <ins> - testname: CSIDriver, lifecycle codename: '[sig-storage] CSIInlineVolumes should run through the lifecycle of a CSIDriver [Conformance]' description: Creating two CSIDrivers MUST succeed. Patching a CSIDriver MUST succeed with its new label found. Updating a CSIDriver MUST succeed with its new label found. Two CSIDrivers MUST be found when listed. Deleting the first CSIDriver MUST succeed. Deleting the second CSIDriver via deleteCollection MUST succeed. release: v1.28 file: test/e2e/storage/csi_inline.go </ins> - testname: CSIInlineVolumes should support Pods with inline volumes codename: '[sig-storage] CSIInlineVolumes should support CSIVolumeSource in Pod API [Conformance]'

Discussion:
[X] test approval issue : [X] test pr : 26 May 2023 [x] two weeks soak end date : 9 June 2023 [x] test promotion pr : [x] remove endpoint from [x] End of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. According to following APIsnoop query, there are still 3 CSIDriver endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 3 endpoints. The e2e logs for this test are listed below. This query shows the following csiDriver endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
/reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection.
Reopened this issue. <detailsIn response to : /reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. 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
Change:
// referenced by the pod spec. If visitor returns false, visiting is short-circuited. // Transitive references (e.g. pod -> pvc -> pv -> secret) are not visited. // Returns true if visiting completed, false if visiting was short-circuited. <del> func VisitPodConfigmapNames(pod *api.Pod, visitor Visitor) bool { VisitContainers(&pod.Spec, AllContainers, func(c *api.Container, containerType ContainerType) bool { </del> <ins> func VisitPodConfigmapNames(pod *api.Pod, visitor Visitor, containerType ContainerType) bool { VisitContainers(&pod.Spec, containerType, func(c *api.Container, containerType ContainerType) bool { </ins> return visitContainerConfigmapNames(c, visitor) }) var source *api.VolumeSource

Discussion:
Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). This is usually correct, these methods are often used to drop fields and in this case should visit all containers that are persisted regardless of whether they're disabled, but the callers of these methods should signal that explicitly rather than relying on the implicit behavior. /cc /priority important-longterm /kind bug /sig node
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). /priority important/long-term /kind bug /sig node 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
are you interested in taking this one, too?
VisitPodSecretNames and VisitPodConfigmapNames already specify AllContainers for VisitContainers Can you let me know what else needs to be done?
Callers should specify whether they want to visit all containers or not. There are valid reasons for each, so we shouldn't assume the desired behavior, even if 100% of the current users want to visit all containers. Jordan's original comment in has some examples of current uses. I don't think this needs to be as configurable as , so my naive first attempt to implement this would probably just be a new to and
Change:
lastResult results.Result // How many times in a row the probe has returned the same result. resultRun int <ins> // If set, skip probing. onHold bool </ins> } // Creates and starts a new probe worker.

Discussion:
Happened in GKE suite:
Does it need a liveness probe, maybe?
to delegate
Saw
Can you take a look at this one? Thanks!
FWIW, I saw some fishy messages in in (node: 104.197.48.84) It seems like docker was giving conflicting view of the container status, i.e., whether the container was running or not (and whether kubelet should kill it). kubelet's first attempt to kill the container : All the exec well after the grace period still shows that the container is the "Running: true" state () Later, kubelet tried killing the container again and failed because container does not exist. Note that after the failed kill also shows that the container was in the Running state. At the same time, cadvisor observed the container being stopped but then detected the container and then tried adding it again, but failed to find the /cc UPDATE: According to supervisord, docker was not killed during this time.
I didn't find result for the first Killing, does that really return? What is the log level, I remember that you told me before the log level in GKE is 2?
AFAICT, the pod worker may have never returned because the specific pod worker didn't log anything beyond that point. I was looking at (docker stop hangs) to see if it's relevant. didn't print any error though.
Yeah, the last SyncPod log was which is before the first Killing. Then the pod worker was stuck in
This really looks similar with I tried to reproduce it following the comment. The container was not actually killed. Docker stop hangs. Docker ps shows the container is still running. But the difference is that when I tried to kill it with another , it still hung there.
I was able to reproduce this quite easily by running 30 pods with the same spec in the test and with :
From
My theory is that during may cause docker to leave the container in a unrecoverable state (yep, a bug). I can consistently reproduce this by simply creating (which always fails), and leave the cluster for < 10 min. The restart counts of some of the pods will stop increasing after sometime, and after ssh'ing in to the node, one can easily confirm the same symptoms posted above. If pods use the http probe, they do not have this issue.

For the workaround, we can instruct the probe workers to stop probing after detecting a liveness check failure, until the container has been restarted (with a new container ID). Note that this is just a workaround, as it doesn't stop other components or users to run during this window. I've verified that with this fix, there are no zombie docker containers anymore. Will upload a PR.
FWIW, I also tested it with docker 1.8.3, which has the same problem.
Thanks !
Change:
# they will not be re-generated by 'make'. kube::build::rsync  --delete  <ins> --filter='- /.git/'  </ins> --filter='- /.make/'  --filter='- /_tmp/'  --filter='- /_output/'  --filter='- /'  <ins> --filter='- zz_generated.*'  --filter='- generated.proto'  </ins> "${KUBE_ROOT}/" "rsync://k8s@${KUBE_RSYNC_ADDR}/k8s/" kube::build::stop_rsyncd_container

Discussion:
/kind bug What happened: After k8s master started rsyncing directory, causing hundreds of megabytes to be transferred, making some workflows that utilize remote docker engines impractical. E.g. I use which can start docker-in-docker test cluster on the same remote docker where k8s is built, and currently my Internet connection can only give me about 1 Mb/s, so ~430Mb transfer caused by .git is impractical. What you expected to happen: is ignored as before, unless it's needed by the current script. In case is about to be ed, a warning needs to be printed. How to reproduce it (as minimally and precisely as possible): Just run . Doing so against a remote docker over slow(ish) Internet connection will make the behavior apparent. Anything else we need to know?: For now perhaps only script needs to rsync IIUC (see ). Environment: Kubernetes version (use ): I'll work on this issue.
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 contributor-experience /area build-release
/assign Feel free to ping for review when you have a PR :)
Change:
"io/ioutil" "os" "path" <ins> "strings" </ins> "testing" "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/client-go/kubernetes/fake" <ins> "k8s.io/kubernetes/pkg/cloudprovider/providers/azure" fakecloud "k8s.io/kubernetes/pkg/cloudprovider/providers/fake" </ins> "k8s.io/kubernetes/pkg/util/mount" "k8s.io/kubernetes/pkg/volume" volumetest "k8s.io/kubernetes/pkg/volume/testing"

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? NO Note: Please file issues for subcomponents under the appropriate repo What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubernetes, azure file, chinacloudapi Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others: What happened: We try to mount azure file to pod, and get the following error That is because azure china's storage DNS suffix is rather than What you expected to happen: Kubernetes should provide some method to let user specify storage dns suffix, so we can use Azure file volume How to reproduce it (as minimally and precisely as possible): Any Azure cluster in china can reproduce it. Anything else we need to know: kubernetes has hard coded in shows a relative issue
could you help confirm this?
One possible way is configuring DNS suffix via annotations of PV. If thinks this way okay, I'd like to create a PR to fix it.
azure file was implemented without using resource group or azure cloud provider. The endpoint can be found at One fix is to use azure cloud provider and choose the file service endpoint from azure environment as I did in blob service . Let me know if you can help.
I'm not familiar with azure cloud provider and volume codes. I'd like to try to dig into it to see if I can fix as the way you suggested.