jiebi/CodeConvo huggingface dataset:
Problem: The text on is not working, it should point to these Check the page for the problem. Page to Update: Proposed Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text FlexVolume to and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on is not working, it should point to these Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text FlexVolume to and not to this . /assign /language en 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 issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. 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
This is a Feature Request The red banner introduced with is too intrusive. Most Kubernetes users don't actually care about this deadline, and there is no way to dismiss it. What would you like to be A simple "dismiss" button that sets a cookie to hide the banner in any future visit, like other websites do. Why is this needed I'd argue that most users of the website just want to read the documentation, they aren't going to submit images to that registry, so the warning isn't useful. Comments This could be reused for future banners.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. 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
/retitle Add way to dismiss banners in the K8s website We would implement this for all banners, not just red ones.
/area web-development
oh boy! are you in for a ride!!
xref: also, here's how i deal with papercuts on the web -
Which all banners are you referring to? I'd be willing to take this up.
There's a banner displayed now, it looks like this: ! Imagine if you could click to acknowledge that you'd read it and didn't want to see it again for a fortnight. (separately: does feel relevant - ruled out taking action as they don't plan to push a container image there, which I think reveals a misunderstanding. I think it's worth repeating banners every couple of weeks in case it helps a message to land better).
Which ...To clarify for anyone reading: This banner applies to pulling / downloading container images from the Kubernetes project, this banner is aimed at users, not Kubernetes developers. Nobody can push directly to either of these hosts and the change isn't related to pushing / submitting images.
Thanks and for the explanation! I'll take this up and try to resolve this. /assign
are you working on this issue? I would like to help if you want. Do let me know.
Yes, I'm working on this still, mostly it's completed already, but thanks for the offer!
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]:
As XDRAGON2002 seems is evaded, could you please proceed?
/remove-lifecycle stale
I'll help with this, it seems like a good feature
/sig docs
This is a Feature Request What would you like to be Add a comparison between the CRDs and API aggregation layer. should explain this - but doesn't! Why is this needed It's needed so users can understand the difference between CRDs and API aggregation layers.
/sig docs /sig api-machinery
/trick-or-treat
! <detailsIn response to : /trick-or-treat 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
We can take some reference from this to understand the difference between and .
/triage accepted /wg api-expression
This issue looks interesting. I would like to raise a PR for more explanation. /assign
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: isn't rendering correctly. Proposed Solution: Fix the Markdown for this page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language it /kind bug /priority important-longterm
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --About Some corrections need to be made. Why is this needed JSON in .dockerconfigjson dump is strange. Lack of options for kubectl command. And some more correction is needed. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja
/assign
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]:
/remove-lifecycle rotten because the related PR is under reviewing /triage accepted
This is a Bug Report <!--Required Information--Problem: In Dualstack doc updates for 1.18 , it only removes IPVS prerequisites in but not remove it in , you still can find "Kube-proxy running in mode IPVS" in the doc. Proposed Solution: remove "Kube-proxy running in mode IPVS" in Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /priority important-soon /kind bug – Can you verify the issue described is correct? If so we can tag it as a good first issue and have someone tackle it.
Hi and Thank you very much for raising this. I can indeed validate that the issue is correct and that the proposed solution is correct and would be more than happy to review a PR if someone would be happy to contribute. Thanks again
/assign
– no further action from you needed, this was a small fix. Thank you!
Hello, I noticed some punctuation errors on page /language zh
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. 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
: "Switching to another Kubernetes package repository" and particularly the one for CentOS/REHL shows commands for Debian based system, not REHL based rpm
I'm not seeing this. Can you point out where there are deb commands for RHEL? !
Excuse me it is for old versions: https://v1- https://v1- https://v1- !
I'm also not able to see this for Old version?? !
/retitle Broken tab layout on "Changing The Kubernetes Package Repository" page in older doc versions /kind bug
The problem stems from the existence of two tab layouts on this page having the same name "k8sinstallversions". This issue has been resolved in the branch. To address this issue in old docs versions, we'll need to backport and apply the fix to each corresponding old branch (release-1.25, release-1.26, release-1.27, release-1.28). Considering that the older versions of the documentation are no longer actively maintained, there's a question of whether it's worth investing efforts into fixing this issue.
I don't think it much important!
I'd support a backport. One of the things we do want people to learn to do with older Kubernetes versions is: to upgrade them! /triage accepted /priority backlog
I can try to help with this. /assign
I think the backporting is done which resolves this issue
If it is ok we can close this issue
The fixes have been back-ported to the older release branches. Closing this as completed. /close
Closing this issue. <detailsIn response to : The fixes have been back-ported to the older release branches. Closing this as completed. 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 is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign /triage accepted
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: 1 file changed, 1656 insertions(+), 2119 deletions(-) for Korean is outdated. Proposed Solution: Update according to 1 file changed, 1656 insertions(+), 2119 deletions(-) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
Parent issue :
/milestone dev-1.20-ko.1
/triage accepted
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. 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
/triage accepted
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Client Libraries lists 3rd party software. Kubernetes docs allow content for third-party projects only when: Content documents software in the Kubernetes project Content documents software that’s out of project but necessary for Kubernetes to function Content is canonical on , or links to canonical content elsewhere Proposed Solution: ~Remove links to 3rd party client libraries~ Sort list alphabetically Page to Update: Additional Information: Part of umbrella issue /language en
There was some discussion in about this. What was the outcome?
This is also relevant to
We discussed this in the 2020-06-23 SIG Docs weekly meeting. proposed flagging the third party client libraries with an cautionary note about quality. recommended ensuring that all client projects within are linked to notes that this is strictly content as outside what's allowed in the but that it is useful to a wide user base also points out that client libraries in general (whether in-project or otherwise) are useful to make Kubernetes work as you want it to? This content is unique (there's not a good alternative page elsewhere on the web). What's important is to identifying an owning SIG and having some means to keep the list live and relevant. Removal is held until the end of the v1.19 release cycle, so positive discussion before that date is helpful and I encourage it. /sig community /sig api-machinery we are conflicted about where to put this; we're not sure it fits inside documentation any more - would SIG Community be interested in hosting this list? what are your views on this list, in light of
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : We discussed this in the 2020-06-23 SIG Docs weekly meeting. proposed flagging the third party client libraries with an cautionary note about quality. recommended ensuring that all client projects within are linked to notes that this is strictly content as outside what's allowed in the but that it is useful to a wide user base also points out that client libraries in general (whether in-project or otherwise) are useful to make Kubernetes work as you want it to?
/sig api-machinery we are conflicted about where to put this; we're not sure it fits inside documentation any more - would SIG Community be interested in hosting this list? what are your views on this list, in light of 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
Raised visibility in
sadly some projects under the org is not actively maintained. those libraries (go/java/python/dotnet/js) already linked are fairly active. can we consider to append a new link for C/C++ which is newly & active months ago? i wonder if the community-maintained list is stale b/c it seems rarely updated. also i noticed there's a number of repos stopped maintaining for 1-2 years or even longer period of time: am slighting leaning on keeping the community list as most of these projects are driven by individuals instead of dedicated vendors -- the more we have the better?
Should this issue remain open? Thanks!
I can see one thing that still needs doing /retitle Sort third party client library links so the link text is clearly in alphabetical order. Order by language then by URI.
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
The remaining sorting is straightforward; if it weren't for the issue history I'd say it's a good first issue. /help /kind cleanup
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 : The remaining sorting is straightforward; if it weren't for the issue history I'd say it's a good first issue. /help /kind cleanup 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
Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to
This is an Enhancement Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Add "event" entry to the Kubernetes . Why is this needed s are referenced several times in other definitions, but it is not itself defined.
Caution for people working on this: there is an API in and there is also an audit Event type in . The glossary entry should help readers who are confused between the two /language en /triage accepted
/assign I would like to work on this
Awesome, thanks
I created a new deployment "mydeploy-dotnetcounters" with two containers, one with resource request and limit set and one without. The new deployment had these labels: The HPA for a different deployment "mydeploy" started to fail with: The "mydeploy" deployment had these labels: I resource request and limit to the second container in the "mydeploy-dotnetcounters" deployment and the HPA for "mydeploy" recovered. It seems that the HPA decide what pod to check based on what labels match. However these is no mention of that mechanism in the HPA documentation ( that I could find ). Not here: And not here: I expect the HPA for one deployment to not be affected by the configuration of another deployment. I expect that I can read about the mechanism by which an HPA decides which pods' metrics to examine. Create a deployment with an HPA. Create a second deployment that is a clone of the first, but with an additional label and with resource request cpu not set. No response <details</details<detailsGKE v1.20.11-gke.1300 </details<details</details<details</details<details</details<details</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
/sig docs
/sig autoscaling
This really belongs in the repo /transfer website
/language en /triage accepted /priority backlog /kind feature Thanks for the suggestion
/assign
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: Links in the Terminology section point to (obsolete?) documents. Proposed Solution: Point them at master. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
thanks! Addressed in PR
FEATURE STATE for feature says According to page it is still alpha, being first introduced in 1.22. Should not the FEATURE STATE line then say ?
Page related to issue: /language en
/retitle Empty feature state tag for "Memory QoS with cgroup v2" in "Pod Quality of Service Classes" page /kind bug
We should fix so that the correct feature state is reflected. /priority backlog /triage accepted
It appears that resolving this issue is straightforward. Simply updating the shortcode parameter in will ensure that the correct feature state is reflected accurately. Thanks for bringing this to our attention! /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 : It appears that resolving this issue is straightforward. Simply updating the shortcode parameter in will ensure that the correct feature state is reflected accurately. Thanks for bringing this to our attention! /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
I will want help with this. /assign
'[ API]'s link is 404, there needs a Chinese doc for 'Gateway API'. The website is and the target website is
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. 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
Please describe the issue in English
/language zh
Page related to the issue:
/triage needs-information
My description is already English.
yes, The gateway page have to be translated in Mandarin language.
/help
/remove help This issue is not ready for a new contributor to work on.
/remove-help This issue is not ready for a new contributor to work on.
My description is already in chinese when I clicked on !
The issue is about the page
/assign ops, 404 link, I am working on this.