jiebi/CodeConvo huggingface dataset:
We should add a unit test to Eviction manager that accounts for PID Pressure. The test should cover similar cases as DiskPressure or MemoryPressure. 1) PIDPressure doesn't exist on node. 2) Force PidPressure on node We should include test cases for reclaming resources in terms of pressure and verifying differences between soft and hard eviction.
/sig node /kind feature /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig node /kind feature /help </details
/triage accepted /priority important-longterm
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. 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
it looks like has requested to work on this.
/assign
Hi What do you mean by, "verifying differences between soft and hard eviction."?
It’s the same idea as what we do for disk, memory or inode pressure.
After starting kubernetes cluster on GCE with ./kube-, I cannot connect to grafana dashboard.
It might be related to
How are you trying to access the dashboard - via the proxy or using the nodeIP ?
I'm trying to access grafana via host ip of the node. This is the address written by kube- ``Grafana dashboard will be available at http://XXX.'' Is there a proxy for grafana? AFAIK, we have services with forwarding rules only for elasticsearch and kibana.
We also tried to connect using api proxy (http://localhost:8001/api/v1beta1/proxy/services/monitoring-grafana) and we see sth weird like "{{}}".
That looks like angular crashed part way through. What does the javascript console in your browser show? Brendan On Feb 24, 2015 5:18 AM, "Piotr Szczesniak" wrote:
monitoring-grafana:8 GET http://localhost:8001/api/v1beta1/proxy/ns/default/services/monitoring- monitoring-grafana:11 GET http://localhost:8001/api/v1beta1/proxy/ns/default/services/monitoring- monitoring-grafana:13 Uncaught ReferenceError: require is not definedmonitoring-grafana:13 (anonymous function) monitoring-grafana:19 GET http://localhost:8001/api/v1beta1/proxy/ns/default/services/monitoring-
is it still possible to connect to grafa using nodeIP?
Yes. It should still be possible. The firewall rules are setup on GCE by default to access Grafana. I assume you are running on GCE. , Piotr Szczesniak wrote:
Can you check if firewall rules are setup to access Grafana? , Vishnu Kannan wrote:
I set up cluster using hack/dev-build-and- In Google Developer Console under Compute-Network Load Balancing-Forwarding Rules I can see only the following entries: elasticsearch-logging us-central1 104.154.82.11 TCP/9200 elasticsearch-logging kibana-logging us-central1 104.154.82.224 TCP/5601 kibana-logging
Can you look at "Firewall rules"? , Piotr Szczesniak
OK.
I was running through the vSphere instructions a couple weeks ago and got hung up on the clusterresource issue documented here: Seeing that is was fixed and how i didn't make much progress - I decdied to start over from scratch on a new vm. Now it appears that something is broken on git as seems i cant pull the source anymore -- or maybe the instructions are broken. ( Tried this on two seperate ubuntu 14.04 vms to make sure it wasn't something on first machine) Can't seem to get past this.... go get can't load package: package no buildable Go source files in Maybe i am missing something?
Our root repo isn't actually a go package as there are no buildable files there. Instead I'd follow the instructions here: Where did you see those instructions? I'd love to fix it up.
Thanks for the heads up! I will give those instructions a try. Here is what I was using:
Has that changed recently? I recall copying the initial set of instructions from the GCE guide.
You might have caught a snapshot when the instructions were broken. There was a lot in flight there. I'll send a PR to fix up the instructions.
Thanks .
Tried to create a service on a namespace 'staging' which doesn't exist on my k8s. Creation succeeded which is odd enough :) Then navigating to the entity also works: GET on /api/v1beta3/namespaces/staging/services/redis-service Navigating to the namespace itself produces 404 'namespaces "staging" not found': /api/v1beta3/namespaces/staging/ Getting all namespaces also doesn't list that namespace which sounds reasonable given the above. I'd expect one of the two: standard approach: a clear error that this namespace doesn't exist when attempting to create an entity on it. preferred imo, but better than nothing: creating silently behind the scenes that namespace cc
Sounds like an error configuring your environment. Is this using a standard provider environment or did you install your own? The kube-Apiserver needs the following flags set for admission_control=NamespaceLifecycle,NamespaceAutoProvision,LimitRanger,ResourceQuota In your case NamespaceAutoProvision must not be running. Sent from my iPhone
Admission control option NamespaceExists does your goal for 1. It is what OpenShift uses. NamespaceAutoProvision does 2. It is used upstream right now, but I think upstream should switch to NamespaceExists and require explicit creation, but that is harder to enable for things like e2e until more work is done. Sent from my iPhone
this is the hack/local-up- I didn't find the admissioncontrol set there at all, perhaps it's a bug in that particular setup?
In , for It("should ensure that critical pod is scheduled in case there is no resources available"), kube-dns is used as the critical pod target and being scaled out and in. However, we plan to enable the dns horizontal autoscaling feature in the near future, such as this . If this feature is turned on, the corresponding autoscaler will fight with this rescheduler e2e and maintain the desired number of replicas. Hence this test will be very likely to fail. So probably we should use another critical pod here, or either create a new critical pod that does not exist before in order to protect the ongoing functionalities.
thanks for letting me know. What is the ETA for enabling horizontal autoscaler for DNS?
I believe it would be enabled no later than the 1.5 release.
Sorry to bother, is there an ETA for this? FYI, as merged, we will upgrade the addon-manager to support rolling update for once is ready to go. After that I will start working on enabling horizontal autoscaler for . These will happen before 1.5 code freeze.
Sorry for the delay. fixes this
Thanks for helping!
What happened: The externalName of a Service is not allowed to end with a trailing dot. What you expected to happen: The externalName of a Service should allow a trailing dot. This is very useful to denote a fully qualified value of the CNAME record created by the service and prevent DNS-trial-and-error by appending different (cluster-local) search domains. How to reproduce it (as minimally and precisely as possible): Try to set as a externalName for a Service of type ExternalName. More details The reference reads: RFC-1123 section 6.1.4.3 also states: Also in the errata of RFC-1123 a reference to RFC-1034 is to reiterate on what a legal hostname is. Section 3.1 of RFC-1034 explains the use and validity of a trailing dot. So while one could argue that a valid RFC-1123 subdomain may have a trailing dot, it might still be best to not change the which is used in a lot of places, but instead change the validation locally. Anything else we need to know?: I'll send a PR. Environment: Not much applicable.
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
<!-- 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: After deleting a pod and scaling up the statefulset with different valid envs in the same container simultaneously, then the output events of executing the command is below: What you expected to happen: update successfully. How to reproduce it (as minimally and precisely as possible): a statefulset. apply this statefulset's yaml: After a while, execute , and the pod is running a new stateful's yaml, which a new env key and more replicas. the pod and apply a new stateful's yaml the statefulset Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-28T13:37:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-28T13:30:26Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
/sig apps
Meet same problem while using kube-addon-manager. vs and patchStrategy
+1
In some cases, add in the env which using can solve the problem.
/assign
I think the root cause of this is the strategic patch. As mentioned, we have to use the to fix the problem which tells the strategic patch to remove the field so the spec could pass the validation process of statefulsets. It would lead to API broken if we change the behaviour of strategic merge patch, I'll dig around in the apps validation process and try to find out the solution to this.
Thank you for your reply. According to your advice, I tried to add in my second statefulset's yaml, but I still could not update statefulset correctly. How to fix my yamls to get around the problem?
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
/help wanted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue </details
/assign
Hi , I am new to making contributions in Kubernetes ecosystem. I am happy to start working on this issue. I will reach out to you if I need any clarifications. Best Regards, Umesh
/assign
/assign
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The pods are stuck in with this error: What you expected to happen: I expect the pods to start. How to reproduce it (as minimally and precisely as possible): Running this daemon set on a GCE cluster on (both master and nodes): Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-21T08:23:22Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"windows/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-08-03T06:43:48Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Google Container Engine OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
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 node
/assign
Confirmed the bug in dockershim, filed to fix this.
Changed a environment and didn't make to reproduce the log problem. With provided manifests, the pod did fail in CrashLoopBackOff, but it is because not found in busybox image: And in container status, there is indeed errors of reading container logs: ! After changing the to , it should run properly. Although didn't fix the crash problem, it still helps on termination messages.
Yeah, that's what I thought. The log stuff is not the cause of the crashloop.
Even you create symlink after fail to start container, it still doesn't fix the problem completely. After create the container, there is not log, and if is called at that time, you will still have this error. So the problem is not that we should create symlink after start failure, we should let tolerant log file not exist. Another problem with this issue is that I saw the termination message policy is . Why does kubelet still try to read message from the log?
Maybe we should return empty if the log file doesn't exist? This is because kubelet always fallback to logs if it fails to get from terminationMessagePath (see ).
That if block definitely doesn't belong there...
Or rather, I'm wondering if we should not be reporting the error at all when it's File.
We should never fall back to logs if it is File. Which code would do that (fallbackToLogs or false is always returned)
Opened a change to correctly fall back to logs if the termination message path file does not exist (as we do if the file is empty). While this may actually hide other errors (like ) it matches the intent of FallbackToLogsOnError.
did this work for you? I'm experiencing the same problem and opened an issue here:
these are my logs i am getting in kubernetes.. i am running from jenkins by using kubernetes-plugin making base image as jenkins/jnlp-slave whats this means exactly .. this error? failed to open log file "/var/log/pods/-ebf7-11e7-867e-": open /var/log/pods/-ebf7-11e7-867e- no such file or directory
Maybe you're here because you made the same mistake as I did: My image was trying to execute an ENTRYPOINT in a file that didn't exist. I discovered that by executing:
Windows GCE jobs: [sig-windows] [Feature:WindowsHostProcessContainers] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node [sig-windows] [Feature:WindowsHostProcessContainers] [MinimumKubeletVersion:1.22] HostProcess containers should support various volume mount types Since the jobs were reintroduced. Windows COMPUTERNAMEs are typically limited to 15 characters [1], while the kubelet nodes spawned in the GCE test jobs are much longer (e.g.: `). The names might be truncated, resulting in the test failure. [1] No response /sig windows /sig testing
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
dupe of /close
Closing this issue. <detailsIn response to : dupe of /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
I want to run the e2e test but it failed. Reason: Node name and hostname is longer than 15 characters. But the ComputerName only used the first 15 characters. So they don't equal and the test failed. The e2etest should pass regardless of the hostname length. Deploy a Windows with long nodename (longer than 15 characters). Then, run e2e test. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig testing
Can you show the error message?
STEP: Destroying namespace "host-process-test-windows-2574" for this suite. • Failure [6.334 seconds] [sig-windows] [Feature:WindowsHostProcessContainers] [Excluded:WindowsDocker] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node [It] Nov 21 22:12:49.003: Expected <v1.PodPhase: Failed to equal <v1.PodPhase: Succeeded {"msg":"FAILED [sig-windows] [Feature:WindowsHostProcessContainers] [Excluded:WindowsDocker] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node","total":1,"completed":0,"skipped":1147,"failed":1,"failures":["[sig-windows] [Feature:WindowsHostProcessContainers] [Excluded:WindowsDocker] [MinimumKubeletVersion:1.22] HostProcess containers should run as a process on the host/node"]}
/sig windows does this hostname error ring a bell?
We discussed this a bit on slack, the test is using %COMPUTERNAME% to validate we are running on the host. This value is truncated to 15 chars on windows due to netbios. We could use the hostname, which isn't truncated, with a fallback to computer name for this validation to make the test validate more scenarios. Important to note that some scenarios might not work if in older environments that use netbios but for our test purposes this will work. Long discussion on netbios here:
We'll be working on this as part of a broader windows operational readiness work. Thanks wenli for digging into it.
/assign
Just for broader context... the reason wenli discovered this is, bc we heavily test cluster API over here :), where the dynamically generated host name appends machine-set + cluster characters, so the machines have names like this: to the machines initial name, and it's hardcoded. We want to try to improve this upstream , and have a proposal to do this in flight also:
/sig windows /remove-sig testing
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active 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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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 being fixed by
Reopened this issue. <detailsIn response to : /reopen being fixed by 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
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages 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: Reopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close not-planned [1]:
Closing this issue, marking it as "Not Planned". <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue with Mark this issue as fresh with Offer to help out with [Issue Triage][1] 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