jiebi/CodeConvo huggingface dataset:
The test case "executing a command with run and attach without stdin" is inherently racy. The test runs, and expected to see in the output. The case when the test passes: case 1: Kubernetes creates and starts the container without stdin; The container exits before attach runs; kubectl falls back to get container log, which contains . case 2: Kubernetes creates and starts the container without stdin; kubectl attach before "stdin closed" is printed; kubectl attach contains . The case when the test fails: Kubernetes creates and starts the container without stdin; The container prints "stdin closed", but hasn't exited yet; kubectl attach contains nothing. One example failure: Related issue: Can we modify this test not to check the output? Or use to check output instead? /cc
Uploaded to try to address
/reopen This test is still inherently racy, even after
Fix in (I hope!)
Moving into the current milestone as it was not fixed in 1.14
Hello I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 3 days from now). Do we still target this issue to be fixed for 1.16?
Thanks . PR is available and awaiting review!
What is the PR in question? Is it targeting 1.16 or 1.17?
/reopen This test is having a lot of failures these days
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
is right, it seems to be present in kind jobs now only
/assign let's see if we start to recover a bit of stability :smile:
The rate of failures decreased a lot since last changes Checking the logs of the failures it seems that the problem is that the pod has not finished before checking the output, as Lantao described The test fails Collecting events from namespace The framework logs the pods the kubelet thinks is on the node
note that it's still racy, but it's hopefully somewhat mitigated.
/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
any updates here?
nope, totally agree with the description, is racy by design, couldn't find any way or trick to avoid the randomness
EDIT: It's late and I'm actually not sure I'm remembering this correctly, take this comment with a heap of salt: Specific sub-tests were fixed previously I think, but this one sub-case: That one we can't use the "Wait for stdin input to signal we're attached" hack, so it's just racy and broken. We could remove that case maybe. I'm not sure who I'd want to weigh in on that, probably someone more active in node / CLI.
not super common atm but still happening. discussing
/unassign has a fix for this
[x] test approval issue : [x] test pr : 7 July 2022 [X] two weeks soak end date : 21 July 2022 [X] test promotion pr : According to this APIsnoop query, there is still some remaining ResourceQuota endpoints which are untested. The Status endpoints will be addressed in another test. listCoreV1ResourceQuotaForAllNamespacespatchCoreV1NamespacedResourceQuotadeleteCoreV1CollectionNamespacedResourceQuota Using a number of existing e2e test practices a new has been created for three ResourceQuota endpoints. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the 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
What happened: I have a Kubernetes Cluster with 2 Windows Server 2019 Core VMs as worker nodes. I upgraded first the cluster, and then the first Windows node following the docs here: Every step ran without issue, but the kubelet service was not started. This was not immediately obvious, since "restart-service kubelet" does not propagate the error. I think "start-service kubelet" would be better advice. The logs said: After changing the value of cgroupDriver manually in from "systemd" to "cgroupfs", the kubelet started successfully. What you expected to happen: One of 2 things: Either the Windows upgrade docs telling me what I need to do to fix this, or the kubeadm not breaking the configuration for windows in the first place. How to reproduce it (as minimally and precisely as possible): a windows node to a Kubernetes v1.19 cluster via kubeadm the cluster via kubeadm the Windows node following the docs Anything else we need to know?: Environment: Kubernetes version (use ): 1.20.1 Cloud provider or hardware configuration: OS (e.g: ): Windows Server 2019 Core Kernel (e.g. ): Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others: /sig windows
this may cause by the default value of defaultCgroupDriver cgroupfs Would you provide the from Windows node?
/assign
kubeadm doesn't do anything about cgroup drivers on Windows because cgroups don't exist on Windows. ideally the kubelet checks about this should be skipped entirely in dockershim for non-Linux.
! However, windows docker return as cgroupfs.
probably 's output is the same structure on all OSes with being a default value. this field should not be checked on Windows at all.
/retitle kubelet: don't check for the Docker cgroup driver on Windows
adding since the PR is favorable. /triage accepted
<!-- 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?: /kind bug What happened: call delete endpoint when service is not found. What you expected to happen: It is no need to do delete in controller. Because in service restStorage, endpoint is deleted when delete service. See How to reproduce it (as minimally and precisely as possible): 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:
/area controller-manager /sig apps
/kind bug
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kube-apiserver --help still shows this: It looks like the related feature can be turned off. However, dynamic volume provisioning Alpha has retried in 1.6. What you expected to happen: Remove from feature gate to avoid confusion. How to reproduce it (as minimally and precisely as possible): Run Anything else we need to know?: No Environment: Kubernetes version (use ): 1.7+ Cloud provider or hardware configuration**: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/sig api-machinery
SIG API Machinery doesn't own the contents of the API. /sig storage
What would you like to be : Currently, does not have unit test coverage. Unless there's a strong reason not to, we'd like public facing functions to have unit test coverage. Why is this needed: There's a fairly small chance of GetAddressAndDialer being modified, and thus breaking, in the future without this test coverage. However, it should be relatively straightforward to add the test coverage, and could make a good first issue for a new contributor. There's also the benefit that it helps keep the test coverage in pkg/kubelet high :) And we never know, it might help catch a bug some day :) Extra note I think this ticket could be a great candidate for someone who is new to contributing to sig-node/k8s. I'd prefer to please give first dibs for picking this up to any folks who are currently underrepresented in the k8s community. Please reach out to on k8s Slack (or post directly in #sig-node and tag me) if you're interested, and I'll assign you the issue. I'm happy to mentor and be helpful in whatever way I can :)
/sig node
/good-first-issue
This request has been marked as suitable for new contributors. 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 : /good-first-issue 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
/assign
Hi let's me solve it
Sounds like a plan! Can you please tag and myself for the review?
Hi, I've already created a pr which , please help me complete the review, thanks
hack/build-cross sets it without looking at the current value. And the value has to be an array, which is a bit awkward to use.
This could be improved indeed. Maybe something like and Haven't tested it though... But why would one want to change the value?
I just wanted to build one, so I did the "obvious" thing: hack/dev-build-and-` It failed for multiple reasons :) , Lucas Käldström wrote:
This issue has been a major downer for me. It's much harder right now than it ought to be to articulate the few platforms for which you'd like to build each of server binaries, client binaries, test binaries, etc. Every time I've tried to do this "the right way," I've spent hours looking at scripts and feeling frustrated that build options aren't documented better. Every time, I end up cutting my losses and resorting to temporary build script hacks instead, just to get the job done.
Doesn't fix this issue exactly, but I've found that you can easily build only if you set .
Taking a look at this today, I also thought that setting seems to be the most reasonable.
/sig release
Encountered this error while running on master: Should we set to by default? cc
Why is it empty? Would be better?
seems to expect $(whoami) based on the value of that variable for my machine. I can make that change if you would like.
Can you keep as an option if it is specified? returns a 6 digit numeric value on my machine (corporate provisioned) and that is incompatible with GCI images, as well as error-ing out during e2e provisioning.
that is a great idea, so should be defaulting to whoami in the case where it has not been defined.
OK, will file an PR to fix this.
Filed PR at . PTAL
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Testing bringing up k8s cluster using kubeadm from latest k8s code from master branch. kubelet is not coming up and below is the errors from syslog: upon looking at the code from where the error is happening, it is evident that the err checking is missing. What you expected to happen: deployment to succeed. How to reproduce it (as minimally and precisely as possible): Use the latest code from k8s and build a k8s release and bring up cluster using kubeadm Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): 16.04 LTS (Xenial Xerus) Kernel (e.g. ): Linux e2e--master 4.4.0-21-generic -Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others: /sig node /cc
PTAL
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-enabled-default Which test(s) are failing: CSI hostpath-v0 tests Since when has it been failing: 8/8 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: We need to update client-go to get the fix for selfLink, build new nfs provisioner images, and update them in the e2e test. The fix for client-go is being cherry-picked to 1.15 if you want to use a tagged release:
/assign
/assign
This implies rebase to 1.15.x in external-storage, which seem to be challenging (at least to me :-) )
14 cherry pick also in progress:
OK, I guess this line in the lib is the culprit: So I need to update lib then external-storage to pull it in
I don't think the lib itself needs to be updated. Only updating go-client to get the fix to is needed.
Right, lib doesn't dictate what version of client-go to use. Will wait for client-go release/commit
- thanks a lot for bumping the dependency. Did you have a chance to build the new container with it so that we could update it here:
yeah, opened . (Not sure how to trigger test, or we can just merge and see.)
You can manually create a PVC on an alpha cluster to test.
reported hitting this error: The instance had 4 security groups, and only one of them was tagged. However, the logic around picking the security group is incorrect.. if we get two non-tagged SGs before we see the first tagged SG, it throws an error. We'll want to cherry-pick this to 1.2
I think this one was a victim of flakiness in the auto-assigner when the author is the first-listed maintainer. Assigning to you, :-)
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Report request throttling by the kubelet by default (i. e. V=3) Why is this needed: Request throttling can have serious consequences, but it is reported (in ) at V=4, so not by default. While attempting to probe limits of how many pods per node we could run, we hit a situation where the test pods would go Pending and eventually fail. After investigation, it turned out that the pod was being started by the kubelet, but that status update was not provided to the apiserver in a timely manner, resulting in the pod-to-pod network not coming up, so a pod attempting to connect would time out and fail. The delay was root caused to throttling by the kubelet; raising the KubeAPIBurst and KubeAPIQPS limits resolved the issue. The throttling was caused by fetching secrets for each pod, which was in its own namespace. The subjects of pods/node, namespaces/node, and throttling parameters are complex and I do not propose to solve them here (those are scalability issues that have to be approached carefully). However, being able to easily identify that throttling is taking place without having to restart the kubelet at higher verbosity would help administrators identify the possibility of this issue. My test attempted to create 500 pods across 3 nodes (OpenShift allows 250 pods/node). Running at V=5, I captured a histogram of the throttling delay in seconds. There were 7881 throttling events reported total over perhaps a 45 minute period, with a somewhat bimodal (in this case) distribution:
/sig node /sig scalability
Thanks for filing the pr to fix :)
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
The link in the following sentence is incorrect macOS Install Docker for Mac. See installation instructions . It redirects to instead of The link should get redirected to Navigate to Click on the hyperlink in the below section macOS Install Docker for Mac. See installation instructions . N/A N/A N/A N/A N/A N/A N/A
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
/assign
/sig contributor-experience
Hi, I have been trying to run api-server as an standalone service along with etcd. I am passing etcd-servers and cluster-ip-range as arguments, here is the error I am getting: etcd servers are up and running on that address. Any leads as to how to resolve this? TIA.
This is only happening with go1.8 version, not really sure what is causing issue while parsing the URI.
Caused by this change i believe - CC as 1.8beta1 is being worked on here -
Thanks
I'm getting this exact issue using Kubernetes 1.5.7 and Go 1.8.3. Reverting to Go 1.7 seems to resolve it. This happened after updating a Go 1.7-compiled 1.4.8 Kubernetes cluster to 1.5.7, not sure if that's a corner case. For reference, my stack trace:
cc
Yet another failure
There is already fix in flight
Ok. I see
This was closed 5 days ago but appears to not be fixed. Many PRs have referenced it as a flake since the fix went in.
- I referenced to it 2 after it was closed, but all of those failures were from runs before this was merged. So it's possible that it's already fixed.
When was the fix merged? I saw this a couple hours ago:
Oops, same test but the error is slightly different... Maybe this is a seperate flake
Yeah - it seems to be something different.
Also - I'm not claiming it's definitely fixed - I just said that we need to double check, because the two that I linked was from before merge.
I'll close this one for now. Please reopen the issue and cc us if the flake occurs again.
When working on I a strange issue. It seems that while auto-generating conversions it works fine, but during things like or in the presubmits what is generated is different. Looking into test results: it seems that the order in which the files are processed is different then. /kind bug /sig api-machinery
FTR: The log from above has some debug-logging and panics and the conversion-generator logs are those with
/assign
modifies conversion-gen, but doesn't change the generated files. Did you intentionally exclude those changes? I wonder if it's similar to I checked out , ran I was able to reproduce the error in If that's the case, a workaround to fix the auto-generating is to first remove the affected files and re-generate them locally.
This is supposed to be no-op :) no auto-generated files should change That's not the fix. The problem is with the test jobs themselves: for generating swagger doc, they actually generate different things than they generate when you call "make generated-files" My PR is only a trigger for the problem, it's not a root cause. The auto-generated files are correct, but as part of running swagger docs, we're in-process generating a different stuff.
It looks that packages were missing. has a shorter / list compared to the other checks (e.g. ) when I ran . In the case of , the component-base config package was missing, thus the FIXME code path got hit. The list of packages was derived from . It seems that the dir was dirty during . I'm exploring if we can clean up the dir like does.
It seems that this one isn't yet fully fixed. I have updated the based on the comments on it and a similar issue on that (which I think has a very similar root cause). However, now "govet" and "staticcheck" are failing: [Ironically all other tests are passing, so I think this is again connected to some garbage somewhere] - can you please help with this?
As previously, I can reproduce it by:
I'm fairly sure at this point that the inputdirs param here is too restrictive:
It seems that this commit might be addressing this:
Heh - I think it helped me locally, but it doesn't help for - I probably did something wrong. But I'm fairly sure it's something along those lines that we need to do.
- will you be able to help with it?
So yeah - I was completely wrong. Basically, running with with DBG it clearly is a problem with gen-conversion. And the problem is that we pass only limited input to it: I think we should always pass all inputs - but we should look a bit deeper into it.
OK - so this is the problematic part: We basically process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator.
I actually created a new one, as it seems to be a different thing. Closing in favor of
/triage accepted
/priority failing-test /priority important-soon /kind flake /sig-api-machinery this failure is currently one of the top flake and repros in both Presubmits and CI jobs. This test is also part of the Conformance suite, which makes the flake far more critical. Can one of you please help triage this issue.
/cc
/cc
/assign
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
flakes are continuing, hopefully logging gives us more info to work with
this test seems to flake quite a bit in the presubmits and its a conformance test on top of this. Can we please look into the new logs to see if we have more info to deflake this? Triage: Logs: https://k8s-
/cc
FWIW this test seems to pass consistently in our conformance dashboards - https://k8s-,%20master%20(dev). But seems to flake only in CI and Presubmits
Do those run at different parallelism levels? It could be load/timeout sensitive
I have also seen a general uptick in flakes in other e2e tests that could be sensitive to watch event latency, not just gc tests - for example, see the failures in https://k8s-
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
Hey, this test does not appear to be flaking anymore can we close this issue?
Closing based on non-response. /close
Closing this issue. <detailsIn response to : Closing based on non-response. 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
This was never actually fixed, looks like.