jiebi/CodeConvo huggingface dataset:
<!-- 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 feature What happened: In some files, i found that there are many self-contained function, whose feature is as same as some util function. Obviously, they are redundant. What you expected to happen: Use util function to replace self-contained function 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:
/assign
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
similar comment to Can you edit the description in to say instead of ? Thanks!
Thanks. Done.
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Update the help text for kubelet's flag to explicitly mention that it has no effect over the endpoint. Why is this needed: The help text for kubelet's flag describes it as "Enable cAdvisor json and endpoints." which would seem to include , however this is not the case as that endpoint is required by kube-metrics-server and exposes stats from cadvisor or CRI (depending on the stat provider selected internally). Related Issues: /sig node /sig instrumentation /kind documentation
/kind documentation /triage accepted /help
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 : /kind documentation /triage accepted /help 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 This should be updated in as well as (unless there is some automated process that updates the website from the options in code that I'm not aware of).
To summarize a conversation in slack, it appears there is a documented procedure for updating the website found at The procedure is long, so it is tempting to just copy in the small amount of text that was changed from into a website PR rather than pulling down so many moving parts. In any case, we likely should keep this issue open until both the change to and an associated website change are merged.
can you link to the Slack convo?
Can do - The conversation ended with a question whether there is a bug that would prevent an automated update of the documentation or if we need to submit a PR now that the fix has merged. I searched for an issue but didn't find a match. So we can either try to find someone on sig-docs who might know if there is an issue if it should be updated automagically, or just fix the doc if the website didn't get updated (and I just checked the master branch and it has not been updated yet).
Just in case that is the right answer, I created the PR.
I think the website gets autogenerated upon point releases but that'd be a good thing to clarify with the website team. I'll leave a comment asking as much.
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
probably caused by
Could be a clash between these two?
cc
I still see the issue with local-cluster on the latest master: F0225 17:06:49. ] error: v1alpha1.KubeProxyConfiguration: FeatureGates: ReadMapCB: expect { or n, but found ", error found in byte of ......
looks like that's another issue, can you please file a new bug? with more logs? this one was about none of the hyperkube based processes starting up.
will do as it is also broke container kube-proxy as well. Same type of error.
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-controller repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the sample-apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the kube-aggregator repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the code-generator repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area code-generation /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the client-go repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area apiserver /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apimachinery repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
The purpose of the file for each Kubernetes repository is to provide a list of people who can assist the Kubernetes in the event that a security issue related to the repository is discovered or disclosed. As described in the file, those on the list should agree to our . Please update the  file for the apiextensions-apiserver repository. After finding people who are willing to work in this capacity, you should add them to the list, then remove PSC members (except any PSC member will be working as a security contact for this repository). The list is GitHub usernames, optionally followed by an email address. If no email address is listed, the PSC will use the email address found on git commits made by the listed user. The file may already have people listed who are secuirty contacts. In that case, simply remove any PSC members who aren't also security contacts for the repo. See for more information /area security /committee product-security /kind cleanup /lifecycle frozen /priority important-soon /sig api-machinery
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-e2e-gce ci-kubernetes-e2e-gci-gce Which test(s) are flaking: [sig-apps] CronJob should delete successful/failed finished jobs with limit of one job Testgrid link: Reason for failure: Anything else we need to know: this is the top flake for pull-kubernetes-e2e-gce: triage link: specific failures /sig apps /priority important-soon
this is the second flakiest test (failing on ~15% of PR runs)
I'll look into it. /assign
if there's not an obvious immediate fix, I would recommend: the test as to skip the test in merge-blocking job runs a second PR that reverts the change and adds debugging commits and do on that PR to flush out issues this issue open and in the current milestone to track resolution of the test before release (either by fixing the test, finding/fixing an underlying bug, or proving we have test coverage of the function via another method and deleting the test)
marked as in , will leave this issue open to track root causing, fixing, restoring the test before release
To follow up here, this was confirmed as root-caused, fixed and restored by
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: After starting controller manager, get the following panic: /---------------------------------- I0712 08:54:30. 1 ] Deleting route 10.245.1.0/24 10.245.1.0/24 I0712 08:54:30. 1 ] Creating route for node ab-6l35lzekrg-0-7igjn3vr43tw-kube-minion-abhezrwnqucq 10.245.1.0/24 with hint -655c-11e7-9a48-, throttled 1.602µs I0712 08:54:30. 1 ] Creating route for node ab-hfvphu5tyl-0-623ksgxczeoh-kube-master-oevhfzd3xo7s 10.245.0.0/24 with hint -655c-11e7-9a48-, throttled 651ns I0712 08:54:31. 1 ] Created route for node ab-6l35lzekrg-0-7igjn3vr43tw-kube-minion-abhezrwnqucq 10.245.1.0/24 with hint -655c-11e7-9a48- after 349.278413ms I0712 08:54:32.
1 ] Created route for node ab-hfvphu5tyl-0-623ksgxczeoh-kube-master-oevhfzd3xo7s 10.245.0.0/24 with hint -655c-11e7-9a48- after 1.583805322s panic: runtime error: index out of range goroutine 1250 [running]: panic(0x3a3d4e0, 0xc42001a080) +0x1a1 (Routes).DeleteRoute(0xc4212e15a0, 0x40ff60e, 0xa, 0xc421bf22a0, 0x0, 0x0) +0x7d5 (RouteController).reconcile.func2(0xc4210bed70, 0xc421bf05e0, 0xc421bf22a0, 0xed0f7dac6, 0x3264f461, 0x6f143e0) +0x15a created by (RouteController).reconcile +0x6e6 /---------------------------------- What you expected to happen: Successed to delete route. How to reproduce it (as minimally and precisely as possible): verytime Anything else we need to know?: Environment: Kubernetes version (use ): v1.6.4 Cloud provider or hardware configuration*: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: cc /sig-openstack
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
cc
Reiterating the mentions to trigger a notification: <detailsIn response to : cc 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
HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
What happened: The rbd plugin use "rbd info" error: The messages before and after json result is warning string and no effect to rbd info, but it is effect to parse the output. So the kubernetes will failed: What you expected to happen: Kubernete no failed and errors How to reproduce it (as minimally and precisely as possible): Remove the config file
/sig storage
We are blocked by this issue, can't resize any PVCs
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
That is another situation that cluster configuation is empty, aslo will return lots of warnning information: Also will trigger expand volume failed. But should we add -c=/dev/null in rbd info command?
Folks, the pull request that would have fixed this just got closed as it was rotting away. This is an actual problem in production, can we please fix this?
+1 we are still being plagued by this issue...
+1 {"name":"kubernetes-dynamic-pvc--147e-422c-9e67-","size":,"objects":2560,"order":22,"objectsize":,"blocknameprefix":"rbddata.","format":2,"features":["layering"],"flags":[]}, invalid character '-' after top-level value
I solved by exceuting this command
Wow...I was not expecting this to work ... but it did ;) Any insights on why is it working with just the presence of the file? This is very strange... Appreciate any comments...
What happened: Some of the Azure CSI translation checks in and needs to perform NPE checks for pointer based fields as pointed out in and What you expected to happen: NPE checks should be there How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.15 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
/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
/remove-lifecycle rotten
/priority critical-urgent
For example, kubernetes-ro service appears with empty selector (this service was created by the hack/local cluster) - is that ok? What meaning such service has if it has no entity to fwd traffic to?
kubernetes and kubernetes-ro are currently "virtual" - they are not backed by running pods, but by the master itself. , abonas wrote:
if that's internal impl, why is it exposed to user? let's say a client pulls all entities and builds a UI around it. then a service with no selector arrives, and it's internal to kube - how the client should know not to present it/touch it? (similar to the "net" container in pods)
It's exposed exactly FOR users - so they can find the apiserver. It has a corresponding Endpoints object, it gets a portal IP and a kube-proxy rule, and it gets service env vars and a DNS name. The fact that it is virtual is an implementation detail. That it exists is all users should need to know. , abonas wrote:
And FWIW, the master components may one day actually be pods... , Tim Hockin wrote:
thanks for the explanation. so any general rule how to distinguish kube pods/services from user defined?
Do we need to distinguish them? We could add labels, I guess, if it is really important to distinguish them.
sometimes users would want to see only the things they defined and not implementation details of the system.
One could argue this is why the users should be using labels. I'm not against defining labels for "special" stuff, but it's new territory, so we should enter with caution. , abonas wrote:
I think the right answer might be to put them in a special "cluster" or "system" namespace. , Tim Hockin wrote:
See If we put them in a "kubernetes" ns, the DNS name would be :) I'm not against segmenting them into a different namespace. We just need to decide on what that namespace is called, plumb through that configuration, decide on compatibility for a short while or not, and decide if that namespace is "special" or just "different" - i.e. should the skydns, heapster, etc pods go into this namespace? , Brendan Burns wrote:
As said, the services are there for applications that need to contact the apiserver.
Additionally, nil selectors can be used by users to import external services. Adding labels to the kubernetes services won't help. Users need to manage their objects using labels. /cc
Yeah, lots of consumers will expose "special" services. IN fact, in many clusters the "special" services will outweigh the unspecial ones. At this point, the namespace they are in is completely arbitrary, and I think because it is a name, it should be free for the end user to choose where they are surfaced.
Per the proposal here: , I think the namespace should continue to hold these services, and they require no special labels. I sense comment is made without thinking through what Kubernetes operators do to bootstrap a cluster. I think it's reasonable that namespace holds everything you need to run, and operators may or may not choose to segment their data in other namespaces. If they want to not see this information, its an exact reason for why they should use their own namespace. I don't think we need anything new here.
- I'm not clear on your meaning. Did you mean that we should make the "cluster admin" namespace a config param that everyone knows about and can be different cluster-to-cluster? Or did you mean that default is as arbitrary a name as any other? I'd be fine moving things out of default into "kube" or "kubernetes" or "cluster" or something, but I am less convinced that a flag is a good thing. , Clayton Coleman wrote:
- wherever we stick this stuff, it should be the namespace that is initially bootstrapped, which today is . I continue to believe that is as good a name as any other. I do not see a need to do more here.
I think as soon as you bring naming into the picture, making decisions based on names gets very tricky (what if I want my logging service to be everywhere?). If there is a magic namespace that exposes things to the rest of the cluster, we should ask whether there's only one magic namespace, or multiple? Are services supposed to cross namespaces? It's great that pods can find the master... but that's not the only thing they'll need to find in each namespace. And baking in special names (or customizable names) into your app code is fragile, because then your code only works inside Kubernetes.