jiebi/CodeConvo huggingface dataset:
Change:
# returns a random port kube::util::get_random_port() { <del> awk -v min=1 -v max=65535 'BEGIN{srand(); print int(min+rand()*(max-min+1))}' </del> <ins> awk -v min=1024 -v max=65535 'BEGIN{srand(); print int(min+rand()*(max-min+1))}' </ins> } # use netcat to check if the host($1):port($2) is free (return 0 means free, 1 means used)

Discussion:
It seems like an issue similar to the problem with API server. I'll extend the timeout in the similar fashion. cc
Extending timeout didn't help. It's probably something else.
cc
I think the logs make it pretty clear what went wrong: or does one of you have time to fix this?
The Jenkins docker test image probably needs netcat to be installed. Should be an easy fix; I can take this.
Thanks!
Ugh... neverending story.
This seems like a different problem.
Oh, I see, this actually is the same, but harder: I think the most obvious thing to do is to let kubectl select the port and report back?
reports more occurances. Netcat somehow is no longer installed?
those two are older builds, using , which didn't have netcat yet.
ah thanks!
are you still working on this? Would you like me to take it?
I'm not right now, sorry, feel free to take it.
Change:
} } <del> // Create Pod </del> <ins> t.Log("Creating the pod to schedule") </ins> if _, err := config.client.CoreV1().Pods(config.ns).Create(context.TODO(), test.pod, metav1.CreateOptions{}); err != nil { t.Fatalf("Failed to create Pod %q: %v", test.pod.Name, err) }

Discussion:
Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestVolumeProvision Example: Since when has it been failing: Not sure, and aren't displaying any results /sig storage
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
/assign /remove-lifecycle rotten Still seeing this, although not very frequently. Could indicate a race.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
latest failures:
take as an example the test fails b/c is set to PVC , which is not expected. our volume binder tries to dynamically provision it:
as for the test fails for the same reason when the scheduler volume binder tries to find volumes for PVC , its corresponding volume is not synced to volume binder or synced version is not in Available state so the volume binder will try to dynamically provision it too
I think the root cause is that the scheduler fails to find matching PVs in PV Assume Cache for the PVC because the PV in the Assume Cache is not in Available state or does not exist due to event delay. We should wait for the PV/PVC Assume Cache to be up to date before scheduling the pod.

However, it's not possible in integration tests. I think we can wait for the PV to be available or bound. This should reduce failures.
Change:
"time" "k8s.io/kubernetes/pkg/api" <ins> apierrors "k8s.io/kubernetes/pkg/api/errors" </ins> "k8s.io/kubernetes/pkg/api/v1" legacyv1 "k8s.io/kubernetes/pkg/api/v1" metav1 "k8s.io/kubernetes/pkg/apis/meta/v1"

Discussion:
Three tests now create RoleBindings to give permissions to test service accounts: NodeProblemDetector Ingress PreStop Creating RBAC Rolebindings currently requires the user issuing the create call to have the required permissions. If RBAC is not enabled, and the cluster hasn't been configured with any RBAC bootstrapping, that won't be possible. We should make this test code conditional on whether RBAC is in use.
c.f.
Quick fix is to tolerate forbidden errors there and assume e2e setups using methods other than RBAC have already granted permissions to the service accounts
I'll put together a PR to tolerate the 403 in the test helper.
I think this can be closed now that the e2e RBAC setup is best effort and failures there don't affect the test if another authorizer is in use
I agree. My original thought was that we'd make the RBAC test stuff only happen on RBAC-enabled setups. But, since we're going to be pushing setups towards using RBAC, we might as well have those pieces stick around in the common code (as best-effort).
Change:
glog.V(vLevel).Infof("Image garbage collection succeeded") } <del> }, ImageGCPeriod, wait.NeverStop) </del> <ins> }, ImageGCPeriod, stopChan) </ins> } // initializeModules will initialize internal modules that do not require the container runtime to be up.

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: The kubelet will GC the images on the node to free space when the used space reaching the percent ot the high-threhold(90% as default), but when the containers are not just managed by kubernetes(such as managed by swarm together) and not wished to be GCed by kubelet, I found we can not close the GC function by the flag of image-gc-high-threshold. What you expected to happen: add one switch to close the function of imageGC in specific senario: when the flag image-gc-high-threshold is set as 0, we should not GC the images on the node, just record one warning event to kube-apiserver Or add another switch flag to close the whole function of imageGC How to reproduce it (as minimally and precisely as possible): run kubernetes with several nodes, and test with making the inode all consumed of the nodes then the kubelet can triggle the GC to delete the oldest images on the node regardless the kind of them. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/kind feature
/sig node
What happens when --image-gc-low-threshold and --image-gc-high-threshold are both set to 100 ?
when both set to 100, image GC will still delete one image to release space as it always runs into the logic and delete image in logic of func
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
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
Change:
options.captureProfile(outputProfile) } <ins> f.setInstrumentedPlugins() return f, nil } // setInstrumentedPlugins initializes instrumented plugins from current plugins that frameworkImpl has. func (f *frameworkImpl) setInstrumentedPlugins() { </ins> // Cache metric streams for prefilter and filter plugins. for i, pl := range f.preFilterPlugins { f.preFilterPlugins[i] = &instrumentedPreFilterPlugin{

Discussion:
metrics to see more details related to scheduler's decisions in Filter phase In some cases (e.g. new feature is in scheduler and want to see if it works or not), we may want to see which filter plugin affected Pod's scheduling results and it would be nice if we can observe that in metrics. Ref: /cc /sig scheduling
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
So, your imagined metrics is like counter that has the label (i.e. one counter for one plugin) the count represents how many times did plugin have an impact on the scheduling of the pod. Am I correct? (I'm not sure if I am understanding your imagined metric correctly.)
I would also add an label that can be or . We probably need some common implementation between this and
do you have time to work on this in 1.26?
Yes, I'm gonna take time to work on this (+ ) in the next release. Let me try. /assign
We should probably extend this to Score as well
/retitle metrics to see which plugins affect to scheduler's decisions in Filter/Score phase
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale After supporting Skip in Filter and Score.
memo: is the issue to support Skip in Score.
/cc Will work on part after
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
It's time! /assign
Change:
serv.Flags |= utilipvs.FlagPersistent serv.Timeout = uint32(svcInfo.StickyMaxAgeSeconds()) } <ins> // Set the source hash flag needed for the distribution method "mh" if proxier.ipvsScheduler == "mh" { serv.Flags |= utilipvs.FlagSourceHash } </ins> if err := proxier.syncService(svcPortNameString, serv, true, bindedAddresses); err == nil { activeIPVSServices[serv.String()] = true activeBindAddrs[serv.Address.String()] = true

Discussion:
The current support of the load distribution method and in kube-proxy ipvs mode only performs hashing of source IP address to select endpoints. As a result, all connections from a single client (i.e. from a particular source IP) are always forwarded to only one endpoint matching with the hash value of this source IP. If the client opens a vast majority of connections to the k8s cluster, it will result in traffic imbalance as only one endpoint located on one node handles the connections while the remaining endpoints/nodes are idle. Here is an example of the problem when using method for kube-proxy Deploy a service with 4 endpoints located on 4 nodes.Open 200 connections from a client to node IP of any node (e.g. telnet 192.168.1.1 ). All connections receive replies from only one single endpoint.The distribution printout also shows that all connections are forwarded to the endpoint (e.g. 1.0.4.2:5001 in this example)Similar issue is seen with method Connections from a client should be evenly distributed to all endpoints like to avoid unbalanced load distribution between cluster nodes and endpoints. This can be easily done by enabling the source port hash flag that IPVS supports for the methods which performs hashing on both source IP and source port when selecting the target endpoint.
/sig network /area kube-proxy /area ipvs
This issue was raised based on the discussion of the issue
triage/accepted /assign
/triage/accepted
/triage accepted (damn it!)
Change:
"k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/runtime/serializer/json" "k8s.io/apimachinery/pkg/runtime/serializer/versioning" <ins> "k8s.io/apimachinery/pkg/runtime/serializer/yaml" </ins> schedulerapi "k8s.io/kubernetes/pkg/scheduler/api" // Init the api v1 package _ "k8s.io/kubernetes/pkg/scheduler/api/v1"

Discussion:
Kubernetes scheduler enables you to overwrite default Predicates/Priorities as well as configuring extenders in a "scheduler policy". In latest scheduler componentconfig API (v1alpha1), it can be a file or a configmap: However, if you defines a scheduler config file and specify a YAML policy file: It doesn't work. It's because only JSON is supported: It'd nice to enhance it with an UniversalSerilizer so as to support both JSON and YAML. /sig scheduling /help /priority important-longterm
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Kubernetes scheduler enables you to overwrite default Predicates/Priorities as well as configuring extenders in a "scheduler policy". /help /priority important-longterm </details
/assign
Change:
# Admission Controllers to invoke prior to persisting objects in cluster ENABLE_ADMISSION_PLUGINS="LimitRanger,ResourceQuota" <del> DISABLE_ADMISSION_PLUGINS="ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook" </del> <ins> DISABLE_ADMISSION_PLUGINS="ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,StorageObjectInUseProtection" </ins> # Include RBAC (to exercise bootstrapping), and AlwaysAllow to allow all actions AUTHORIZATION_MODE="RBAC,AlwaysAllow"

Discussion:
What happened: The preparation step of the e2e tests were failed sometimes on my local environment like What you expected to happen: These tests can be passed without any errors. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.13.1 Cloud provider or hardware configuration: OpenStack OS (e.g. from /etc/os-release): 16.04.4 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-138-generic Install tools: kubeadm Others:
/sig storage
After discussing on the PR I have known I need to enable StorageObjectInUseProtection plugin of admission controller which is disabled by default. The corresponding e2e tests require the plugin is enabled, so I think it is better to enable the plugin by default for most users.
Investigation of StorageObjectInUseProtection plugin of admission controller under kubernetes/kubernetes: cluster/centos/config- Enabled cluster/gce/config- Enabled cluster/gce/config- Enabled cluster/kubemark/gce/config- Enabled hack/local-up- Enabled cluster/juju/layers/kubernetes- Disabled This is the reason why we don't face this issue on the upstream CI system, and I it on my local environment which is deployed with kubeadm.
Change:
continue } <ins> ginkgo.By("Removing the finalizer from the pod in case it was used") e2epod.NewPodClient(f).RemoveFinalizer(context.TODO(), p.Name, testFinalizer) </ins> framework.Logf("Deleting pod: %s", p.Name) e2epod.NewPodClient(f).DeleteSync(ctx, p.Name, metav1.DeleteOptions{}, 2*time.Minute) }

Discussion:
Pods that already succeeded and waiting for finalizer are being readmitted, fail to be admitted and moving from Succeeded Phase to Failed (admission failed) phase. The correct behavior would be to not try to re-admit the succeeded (or failed) Pod. Specific case: Node is exposing Devices using device plugin. Device plugin is implemented as a Pod Job's pod that is using the Device run to completion and waiting for Job Status finalizer kubelet is being restarted DevicePlugin pod is reconnecting to the kubelet. While it is reconnecting, kubelet don't have availability of devices kubelet re-admits the Pod, even though it is terminated already kubelet marks the pod as "failed to be admitted" But the same can happen with the variations of GC speed and other admission handlers. /sig node /priority important-soon /cc There is also a wider issue: , that concentrates on running pods. This issue is about terminated Pods, which is less controversial. <detailsFor sure on master, may be on earlier versions. </details<detailsN/A </details<detailsN/A </details<detailsN/A </details<detailsN/A </details<detailsN/A </details
/triage accepted I think we have at least another issue mentioning the same behavior but observed for jobs, I'll look it up and crosslink later
Change:
ginkgo.Context("with immediate allocation", func() { claimTests(resourcev1alpha2.AllocationModeImmediate) }) <ins> ginkgo.It("must deallocate after use when using delayed allocation", func(ctx context.Context) { parameters := b.parameters() pod := b.podExternal() claim := b.externalClaim(resourcev1alpha2.AllocationModeWaitForFirstConsumer) b.create(ctx, parameters, claim, pod) gomega.Eventually(ctx, func(ctx context.Context) (*resourcev1alpha2.ResourceClaim, error) { return b.f.ClientSet.ResourceV1alpha2().ResourceClaims(b.f.Namespace.Name).Get(ctx, claim.Name, metav1.GetOptions{}) }).WithTimeout(f.Timeouts.PodDelete).ShouldNot(gomega.HaveField("Status.Allocation", (*resourcev1alpha2.AllocationResult)(nil))) b.testPod(ctx, f.ClientSet, pod) ginkgo.By(fmt.Sprintf("deleting pod %s", klog.KObj(pod))) framework.ExpectNoError(b.f.ClientSet.CoreV1().Pods(b.f.Namespace.Name).Delete(ctx, pod.Name, metav1.DeleteOptions{})) ginkgo.By("waiting for claim to get deallocated") gomega.Eventually(ctx, func(ctx context.Context) (*resourcev1alpha2.ResourceClaim, error) { return b.f.ClientSet.ResourceV1alpha2().ResourceClaims(b.f.Namespace.Name).Get(ctx, claim.Name, metav1.GetOptions{}) }).WithTimeout(f.Timeouts.PodDelete).Should(gomega.HaveField("Status.Allocation", (*resourcev1alpha2.AllocationResult)(nil))) }) </ins> }) ginkgo.Context("multiple nodes", func() {

Discussion:
When a ResourceClaim: uses delayed allocation does not get created for a specific pod (i.e. not from a template) then it currently gets allocated and remains allocated until: scheduling of a pod fails because the node originally chosen for the allocation isn't suitable, in which case the scheduler triggers deallocation via the user deletes the claim What we want instead is that deallocation gets triggered when the last user of such an allocated claim gets removed from . To avoid races, deallocation must be done through . This can be implemented either as a controller or directly in the API server.
/assign
/triage accepted /sig node /priority important-longterm /kind feature
Change:
} fakeDocker.containerList = []docker.APIContainers{ { <del> Names: []string{"foo--qux--1234"}, </del> <ins> Names: []string{"/k8s--foo--qux--1234"}, </ins> }, { <del> Names: []string{"bar--qux--1234"}, </del> <ins> Names: []string{"/k8s--bar--qux--1234"}, </ins> }, } fakeDocker.container = &docker.Container{

Discussion:
release-master-blocking Conformance-GCE-master-kubetest2Kubernetes e2e suite.[It] [sig-network] Services should be able to change the type from ExternalName to ClusterIP [Conformance] ci-kubernetes-gce-conformance-latest-kubetest2.Overall kubetest2.Test 07-11 15:51 EEST No response /sig cloud-provider 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
I remember some timeout has changed with ginkgo2 and something moved from 24hours to 1 hours, or something like that, is it possible that this is the problem here, in this job?
The Grinko timeout change could also be the root problem with this job:
hmm, we have to revisit the flags
hmm, this seems correct
that was a good observations, seems that job is failing because gathering the logs takes too much time !
there is no timeout set in the kubetest2 command here (not sure if this would be the place to set a timeout)
it seems kubetest has to be migrated to ginkgov2 it should use this as basis I'm on vacation this week, can somebody take over and open the issue and patch kubetest2?
looks like this file needs to get updated: add line 72:
oh, you already commented this :D
I will have a look later
Related: umbrella issue:
last testgrid run passed :)
Change:
framework.ExpectNoError(err) e2eservice.WaitForServiceUpdatedWithFinalizer(cs, svc.Namespace, svc.Name, true) }) <ins> ginkgo.It("should find a service from listing all namespaces", func() { ginkgo.By("fetching services") svcs, _ := f.ClientSet.CoreV1().Services("").List(metav1.ListOptions{}) foundSvc := false for _, svc := range svcs.Items { if svc.ObjectMeta.Name == "kubernetes" && svc.ObjectMeta.Namespace == "default" { foundSvc = true break } } framework.ExpectEqual(foundSvc, true, "could not find service 'kubernetes' in service list in all namespaces") }) </ins> }) // TODO: Get rid of [DisabledForLargeClusters] tag when issue #56138 is fixed.

Discussion:
This issue proposes the writing of a new test for the API endpoint with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. There are no tests listing services, see the following: This mock test uses client-go's functions and hits the endpoints. This shows the endpoints hit by my approach: /sig architecture /area conformance
Change:
"//pkg/api/legacyscheme:go_default_library", "//pkg/cloudprovider/providers/gce:go_default_library", "//pkg/scheduler:go_default_library", <ins> "//pkg/scheduler/algorithmprovider/defaults:go_default_library", </ins> "//pkg/scheduler/api:go_default_library", "//pkg/scheduler/factory:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library",

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.