jiebi/CodeConvo huggingface dataset:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): statusFailure 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 ): 4 Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: Others What happened: In FlexVolume code: The statusFailure constant should have string literal "Failure", not "Failed". Because in the test code or documentation everywhere, only "Failure" string is used, not "Failed" for the flexvolume cmd output status string. So this is a typo bug. Here is the test: here is the documentation: here is the example: What you expected to happen: The statusFailure constant should have string literal "Failure", not "Failed" at this line: How to reproduce it (as minimally and precisely as possible): code inspect: Anything else do we need to know: nothing else
<!-- 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: There will be error when kubelet restarts on a agent if pod in that agent has an azure disk mounted, the error would be like following: azureDisk - No t a mounting point for disk andykubewin175-dynamic-pvc--92c7-11e7-b86b- on varlibkubeletpods-92c7-11e7-b86b-volumespvc--92c7-11 e7-b86b- What you expected to happen: pod could still works well even if kubelet restarts on the agent How to reproduce it (as minimally and precisely as possible): consider following scenario: A pod mounting an azure disk in a k8s agent The kubelet is restarted in that k8s agent The pod could not start up, it always reports error as following: 4d 1m 3065 kubelet, 14777acs9000 Warning FailedMount MountVolume.SetUp failed for volume "pvc--92c7-11e7-b86b-" : azureDisk - No t a mounting point for disk andykubewin175-dynamic-pvc--92c7-11e7-b86b- on varlibkubeletpods-92c7-11e7-b86b-volumespvc--92c7-11 e7-b86b- 4d 1m 3157 kubelet, 14777acs9000 Warning FailedMount Error syncing pod Anything else we need to know?: Environment: Kubernetes version (use ): 1.7, 1.8 Cloud provider or hardware configuration**: azure OS (e.g. from /etc/os-release): Kernel (e.g. ): 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 .
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: Since when has it been failing: It has been consistently failing since 3/6, flaking a lot before that. Failure coincides with . Testgrid link: Reason for failure: cc /kind flake /kind failing-test /priority important-soon /milestone v1.14 /sig cluster-lifecycle
sig gcp may be of help here /sig gcp
/assign for routing from SCL side. These are google owned tests.
Looking into this now. Any other googlers also doing so feel free to ping me :-)
Looks like this bug is known with a fix in flight: cc
/assign
Thanks ! Will keep an eye on this for 5 consistent passes, will reopen if there's a problem.
/reopen Most gke jobs are able to create clusters now, however the serial jobs are still seeing failures
Reopened this issue. <detailsIn response to : /reopen Most gke jobs are able to create clusters now, however the serial jobs are still seeing failures 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
Nevermind, it's because the serial job with the fix is still running. I've verified that the cluster creation succeeds in the latest job. /close
Closing this issue. <detailsIn response to : Nevermind, it's because the serial job with the fix is still running. I've verified that the cluster creation succeeds in the latest job. /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
/area platform/gke <img width="1106" alt="Screen Shot 2019-03-16 at 12 00 52 PM" src="https://user-"Think we're done here
I have observed the DNS pod sometimes getting stuck. Need a health-check that tries to do a lookup or something like that.
also DNS should probably come up with N=2 by default
Why is this attached to 1.0 if it's P3? One of those is wrong.
Health checks I can believe. We're in the process of doing that for everything else -- Nothing else is HA, so I don't buy N=2 for DNS but not for other components.
Other components are somewhat harder to make HA. DNS is trivially HA-able. But not too important, it's available after the fact, too. , Brian Grant wrote:
so you mean a generic solution for health checking, or just you are adding health check for other service. In other words should I start adding health check for DNS?
I'd still like to see a health-check for DNS, but I am not sure what is appropriate, though. Maybe have kube2sky open an HTTP server and answer /healthz iff it can complete a non-existing DNS query? Better ideas? It seems the collected other fixes add up to a more stable DNS server? , Piotr Szczesniak wrote:
I assume this is about adding liveness probes to one or more of the containers in the dns pod: Is dig in the skydns image? We could use an exec probe to perform a DNS query.
duh, exec probe is obviously better :) But it doesn't need to get a name, it just needs to complete and not hang. so something like sh -c "alarm 5 nslookup foobar" maybe? , Brian Grant wrote:
leaving unassigned since I'm not working on it right now
are you currently working on this? If not, I'll grab it. Thanks! --brendan
I think that was looking into this today.
Yeah, I sat on it a little today due to not being able to get it to actually work, but I'm pretty sure it wasn't working because exec liveness probes as a whole are broken (). Sent PR to resolve this once exec probes are functional.
The needs updating to be in line with community agreed trajectory for the movement of cloud provider code out of k/k. For example the current statement: This statement is approximately 16 months old and implies there is still ambiguity, where there is now a much more clear plan which should be clearly communicated to those who might waste their time investing work in modifying something in this directory. The situation is one increasingly past maintenance mode, with out-of-tree implementations the goal in the 1.13 cycle followed by removal of in-tree provider code a few cycles later. See also discussion on slack: /kind cleanup /priority important-soon /sig cloud-provider /assign
Thanks for the reminder Tim, sorry this fell off my radar, will put together a PR today :)
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 Need to update the README again to link out to the enhancement issues per cloud provider.
PTAL :)
awesome
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
<!-- 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: Scheduler performance test does not work: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Run schedulerperf by following: 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:
/assign
/sig scheduling
/kind failing-test Not sure if flake. Gubernator is showing a big spike in failures that started 06/14 around 10:00 ~UTC~ PT. This seems to be when merged. Failed on my PR: /sig testing
/sig api-machinery
/cc
filed I'm hesistant to bump it all the way back to 240, if you follow back the original PR / issue trail I ran a number of iterations of testing and it really shouldn't take 240s. four minutes is ludicrous for unit testing one package.
there are 39 failures in the last day in from timeout :/ /priority critical-urgent
Did any timed-out run produce any logs?
we capture the test logs but itself doesn't appear to have any.
e.g. at random (from triage above) ="raw build-" I'm not sure this code emits any when it fails.
Likely it's timing out on some step, but I would have expected some logging from something related -- I was just going to look at the last thing logged and figure that something after that must be the culprit. Does that log capture stderr and stdout of the test invocations?
it should, e.g. see a different kind of failure with logs: we're running with json output formatting then through to junit, and prow will capture stdout/stderr of whatever is running within the job as build-
reopening to keep an eye on this.
sigh: 180s
it's doing better (all recent runs passed, looks like 3 flakes due to this since the PR merged this afternoon) but we may still want to bump it again
We're at 100% pass rate the past 3 hours but CI is not very active right now. still just 3 fails. If we have a similar rate tomorrow morning I'd opt for another small bump (maybe 180s -190s) to cover remaining limited flakes still over going all the way back to 4 minutes.
If we knew which sub test was slow when it is slow, that would possibly narrow it down to a haystack small enough to look for needles in.
dug into it locally, follow up in:
Fairly confident this is now fixed after
closing as fixed by
confirmed
example:
that run happened at the fix merged at
it's impossible to GET replication controllers on v3. on v1 on the same server it works fine. example request: GET on http://localhost:8080/api/v1beta3/replicationControllers returns 404 http://localhost:8080/api/v1beta1/replicationControllers returns 200
v1beta3 moved to all lower case URL Would give that a try first Sent from my iPhone
looks like it's working. but it breaks backwards for clients who worked with v1. For instance, in my gem I can't now smoothly work with both versions because I need to treat the name of the resource differently. why don't at least redirect those who call replicationControllers to the lowercase too? Also, there's no way to know which resources are available and their names. A lot of REST api on their most top level at least publish the links to main resources, but if I call: http://localhost:8080/api/v1beta3/ it returns 404
Because we are actively trying to drop support for mixed case prior to 1.0, I did not continue supporting the old url paths. If you look at the go client, we have a "legacy" flag we use to control this and a few other behaviors.
well yes, but breaking backwards creates more work for the users... more "if this version ..." kind of stuff.
We got v1bet1/2 wrong and don't want to carry it forever. Stopping it early before v1 is our priority.
ok :( are the REST apis going through any kind of design review or code review?
v1beta1 is really an alpha quality API. It grew organically and did not go through any kind of design review, as evidenced by the many issues you've filed. We want to get rid of it ASAP. We intend v1beta3 to be the "release candidate" for the v1 API, which will be the stable API. As for knowing what exists, you can now browse or GET . Additionally, pull is in progress, and will return a list of valid paths to GET .
thanks. will check swagger for now
build only 2 runs are available. ERROR: () build -dd5a-468e-9a7a- completed with status "FAILURE" [33m1 warning found (use --debug to expand): [0m - InvalidDefaultArgInFrom: Default value for ARG ${RUNNERIMAGE} results in empty or invalid base image name (line 16) Dockerfile.windows:22 20 | COPY etcd etcdctl /usr/local/bin/ 21 | COPY migrate-if- /usr/local/bin/ 22 | COPY migrate 23 | 24 | # NOTE(claudiub): docker buildx sets the PATH env variable to a Linux-like PATH, ERROR: failed to solve: mkdir /var/lib/buildkit/runc-overlayfs/cachemounts/buildkit3627953617/usr/local/bin: not a directory make[1]: Leaving directory '/workspace/cluster/images/etcd' make[1]: [Makefile:132: build] Error 1 make: [Makefile:217: sub-push-image-windows-amd64-1809] Error 2 ERROR ERROR: build step 0 "" failed: step exited with non-zero status: 2
2024/07/25 02:39:53 Failed to run some build jobs: [error running [gcloud builds submit --verbosity info --config The etcd 3.5.15 post CI failed to build the image. needs to promote the image: This is post submit CI for /sig release etcd
/cc
can you please try this?
cc Folks, We could use your help fixing the etcd image for windows!
/triage accepted /priority important-soon
actually passed in
POD is OOM. k8s v1.19.4+docker is OK. but v1.21+cri-o+buildah does not work properly. Why the limits are not effective.Not the container limit memory, It's physical memory centos7 kernel use limits memory use -XX:+UseContainerSupport Cannot read memory.limitinbytes k8s version cri-o version buildah version oracleJdk or openjdk have same problem It is normal to use xms and Xmx
/sig node
Supplement v19+docker v21+cri-o+buildah
/assign taking a look, thanks for opening the issue
seems relevant, have you checked your kernel supports the memory cgroup (I know docker does work, but let's sanity check first) I checked on my machine (fedora 34) and successfully can see usageinbytes in a container on our latest 1.22 branch. also, attaching the crio logs will likely help me debug
also curious about the runc version
cri-o logs runc Looks like a problem with cgroup v1
hm the memory cgroup seems to be enabled. what is the image you're using?
centos7.9.2009
/triage needs-information
what cgroup manager are you using?
kubeadm kubectl config crio ps aux|grep kubelet
I seem to have found this bug Delete the following two items to return to normal. deployment
that is unexpected... Great find!
Does the problem manifest if either are different? (hostNetwork: false, but dnsPolicy ClusterFirstWithHostNet)
hostNetwork: true hostNetwork: false delete hostNetwork and dnsPolicy
Rocky 8.4, kernel-5.4, kubernetes v1.21.4 has the same problem
ah! I found the issue
thanks for your patience
Is crio 1.21.3 fixed? This problem still occurs after the upgrade. Branch v1.21.3 did not see the commit
no the initial PR hasn't merged yet, I will try to revive it
sorry this fell through the cracks, I'll try to get this through ASAP
will get it in 1.22.1. is that sufficient or would you like it backported to 1.21?
Thank you Both are OK, I currently use java -xmx instead.I will update in the next version. Preferably v1.21, v1.22 version I will upgrade later.
I've opened as well :)
/remove-triage needs-information /triage accepted /close as this is being tracked as a CRI-O bug
Closing this issue. <detailsIn response to : /remove-triage needs-information /triage accepted 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