jiebi/CodeConvo huggingface dataset:
"Ander Installationsmethoden" here should not be a link to github but to this link:
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
/language de /kind cleanup /priority backlog Actually should either redirect to the (English) page, or it should be a stub that links there and explains that the documentation for Minikube is not localized.
/assign
In section it is said: The CRD can be either namespaced or cluster-scoped, as specified in the CRD's That text is wrong (a CRD object and the custom resource created from that CRD object are not the same). It should better say: The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's field
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
/wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix?
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix? </details
Thanks Yes, I am raising the PR. It is to be the first one I am creating against kubernetes documentation. Anything I should take care of? (thanks in advance ;-)
I found all details in . I am then following it ;-)
/wg api-expression
you've found the right guide. I hope it covers everything you need to know, but if it doesn't then please feel free to ask questions.
I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign /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 : I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign 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
Saw this good first issue with no one assigned, I could take it up /assign
Thanks a lot for putting hands on this ... and sorry a lot for not having done it myself as initially proposed (I was disconnected for some long time).
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: The port-forward command description is misleading. As a user I would expect the command to forward the complete traffic from port 6000 to 5000 locally, not only the data from both ports like the explanation in the detailed command page mentions. Proposed Solution: You could change the description to something like in the detail command description () or change the command to the version it describes. (kubectl port-forward my-pod 5000:6000 -with colon) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
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: After creating and scaling deployment using command kubectl create deployment cattle -- kubectl scale deployment cattle --replicas=5 When we execute below command to list pods with options -l kubectl get pods -l run=cattle O/P is No resources found in production namespace. Proposed Solution: kubectl get pods -l app=cattle Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
can you / have you confirmed that this is a bug? If so, it's be good to record this issue as /kind bug
Yes, this is a bug. When was changed to , the label should have changed from to . This needs to be updated on a couple of other pages as well. /kind bug
/priority backlog
In the table of of there are two descriptions missing of two tolerations kyes, one is another one is , their descriptions are missing.
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 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: The description about emptyDir sizeLimit in page mentioned that: But the following code shows that if no size is specified, size limit defaults to node allocatable memory. Here is the information about my local environment and the result: Proposed Solution: Change this description to the following: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign /language en /sig storage
Could I ask that why it says that if no size is specified, memory backed volumes are sized to 50% of the memory on a Linux host in the document? Why would memory backed volumes be sized 50% of the memory on a Linux host? Is it because the tmpfs default size=50% of physical RAM?
/remove-sig storage /sig node
/triage accepted
The memory-backed EmptyDir by default consumes a very large amount of memory (documented as , but actually ). I think it's too large for the default. In fact, one pod can occupy most of a node's memory. Is there any way to limits the size of memory-backed EmptyDir by cluster admin?
I'm not aware of any existing mechanisms to automate the setting of for volumes. You may have to devise your own mutating webhook or wait for the mutating admission policy to land. -- my 2 cents.
Thank you for your advice! But it's problem that the whole of cluster can be down easily by few pods and the cluster admin can not control this, IMHO. I have a few idea for this problem: Set the default size of memory-backed EmptyDir fewer. e.g. 50Mi. Enable to be controlled the total size of memory-backed EmptyDir Add taint to node for that memory-backed EmptyDir can use WDYT?
I'd like to discuss about this in . Thanks!!
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
/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
Source IP for Services with Type=ClusterIP Packets sent to ClusterIP from within the cluster are never source NAT'd if you're running kube-proxy in iptables mode, (the default). You can query the kube-proxy mode by fetching http://localhost:/proxyMode on the node where kube-proxy is running. kubectl get nodes The output is similar to this: NAME STATUS ROLES AGE VERSION kubernetes-node-6jst Ready <none2h v1.13.0 kubernetes-node-cx31 Ready <none2h v1.13.0 kubernetes-node-jj1t Ready <none2h v1.13.0 When I use kubectl get nodes there is no nodes available except NAME STATUS ROLES AGE VERSION minikube Ready control-plane,master 38m v1.20.2
Let's update to recommend running this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. /retitle Unclear requirements for “Using Source IP” tutorial
/triage accepted
The tutorial uses a cluster as an example setup throughout the document. <sub(The text in the screenshot below is the exact section referred in the issue description)</sub! But as pointed in the description of this issue: the section doesn't clearly state that it requires a multi-node cluster to follow through the doc examples. also, it mentions to create a cluster using which usually is taken as a single node (common) control-plane/worker-node setup. As suggested by the fix/solution would be to update the section to mention that it is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. You could also update the part by linking to this article talking about .
/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 : /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 is a Bug Report <!--Required Information--Problem: All the hyperlinks which are pointing to this are broken. Proposed Solution: I suppose it should point to this now. Page to Update: /language en <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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
Can I work on this?
/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: At 181 line: Link to OpenAPI v3.0 validation is broken. Yes. Most validation can be specified in the CRD using . Proposed Solution: Yes. Most validation can be specified in the CRD using [OpenAPI v3.0 validation](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation). Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign
kubeadm init kubelet kubee-system kubelet-config ConfigMap kubelet kubelet kubelet API kube-system
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
Thanks for the feedback, a fix has been submitted. kube-system kubee-system
This is a Bug Report Problem: Issue clarified privileges of kubectl debug node (through PR ) including " will fail" but in newer versions of Kubernetes 1.25 on EKS, works, although there may still be permissions issues as before. Proposed Solution: Change to " may fail" Page to Update:
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
Created PR
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: The Minikube playground (pages such as ) launches Kubernetes v1.17 This is a shortcoming because there is drift between what we're documenting in pages like , and what actually works in the Katacoda environment. Proposed Solution: Update the Katacoda playground to use a newer version of Minikube and hence a newer Kubernetes cluster version. Page to Update: (and others that use the shortcode) Additional Information: /priority important-longterm
This causes:
/triage accepted
like this:] [URL of the embedded terminal] view- [Content of ] I digged these pages but could not find where to update to change the minikube & K8s version:
do you know / can you recommend someone who can help explain where we might open a PR to update this?
Let me find out for you. The person is away this week so expect a respond next week.
Was there an update on this? Would be happy to help get this updated if needed.
Sorry for the delay. It was caught up with other conversations. I've raised a PR in It will now use K8s 1.20 which is the latest available in Katacoda. I haven't tested the build yet but will do once ready and will update accordingly. Update: Tested the preview build and looks to be working as expected.
I was reffering to minkube version not kubernetes version. is it possible to re-open the this issue
It seems that you have already opened another PR that addresses the Minikube version of Katacoda issue.
found typo "ontrolPlaneEndpoint" in the below <img width="862" alt="typo ontrolPlaneEndpoint" src=""There is a typo "ontrolPlaneEndpoint" in the localAPIEndpoint description it should be "controlPlaneEndpoint"
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
Page related to issue: /language en
/retitle Typo in auto-generated "kubeadm Configuration (v1beta4)" reference page
The mentioned reference page for "kubeadm Configuration (v1beta4)" is . The page is generated from the upstream source code . As the page is generated from the upstream source code, any fixes would need to be addressed there. For those interested in contributing to resolve this issue, please refer to the upstream contribution guidelines outlined at:
/sig docs
this is not a typo in the code files and also in my browser it's shown as controlPlaneEndpoint, so maybe it's a rendering issue. ! cc
but again, there are no typos in the code / go docs. also NOTE that v1beta4 is WIP API that should not be used yet by users.
the in is also dropped in another place on that page, screenshot below. I'm not familiar with the autogeneration for these pages, is there some processing on the word that is dropping letters when converting from the original? Looks like in the source file its written with a capital and in the generated file its with a lower case. Not sure why it would only so it sometimes though. We should check to see if this is happening on other pages. /priority awaiting-more-evidence <img width="789" alt="Screenshot 2024-03-27 at 9 44 26 AM" src=""
Another interesting observation looking at the - it appears to only happen on the v1beta4 version of the docs, not the previous versions. Looks like it was modified with .
Put up a fix in . It looks like this wasn't from an autogeneration error and just a simple typo when the docs were updated for v1beta4.
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 Update to follow v1.19 of the original (English) text. Why is this needed is outdated. Comments /language ja /good-first-issue File to update Original diff between translated and v1.19 Note Currently, we use dev-1.19-ja.1 branch. Please open a PR targeting the branch. ref If you have a question, feel free to ask us at #kubernetes-docs-ja channel.
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 : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Update to follow v1.19 of the original (English) text. is outdated. /language ja /good-first-issue Currently, we use dev-1.19-ja.1 branch. Please open a PR targeting the branch. 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
/triage accepted
/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: The example Ingress contains rewrite annotation: But with new ingress 0.22 + capture groups must be explicit, see As result this example rewrites all paths with / - it does work for simple example, but it breaks any more complex web service! So if some body uses it as template and edits it for his own use case, can get into trouble, which are bit tricky to detect. Proposed Solution: Just delete rewrite-target annotation and ingress will work as expect by default. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
issue page: /language en
Starting in Version 0.22.0, ingress definitions using the annotation are not backwards compatible with previous versions. In Version 0.22.0 and beyond, any substrings within the request URI that need to be passed to the rewritten path must explicitly be defined in a capture group. As this is simple ingress example so no rewrite example is needed
/triage accepted
/assign
Page to be updated: What needs to be done? section needs to be updated per and For technical accuracy and/or reference, you may also check PR /sig network /help /good-first-issue cc:
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 : Page to be updated: For technical accuracy and/or reference, you may also check PR /help /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
I am beginner and i want to contribute on this issue. Can you please guide me for this issue??
Sure, Please read and . After going through both of the resources, please could you let us know what more information would you need from our side to begin working on this issue?
can I work on this issue?
Hello everyone! Anyone looking at the issue - please note that you do not need my/anyone else's permission to work on an issue. If you are signing the and abide by the please feel free to pick up the issue. Additionally, please note that for every issue under sig docs it's always OK for anyone to open a pull request to work on it, including this one. If starting work, it's nevertheless polite to try to liaise with anyone who has already opened a PR or otherwise expressed an intention to work on the issue.
/triage accepted /priority backlog
i checked the both and . but i haven’t find any difference in actual documentation. it seems correct to me. would you like elaborate me.
Both those comments point to a change that is required in the Kubernetes Network Model section. The current phrasing is not technically accurate. For reference, you ALSO need to check the PR because it will give you the correct phrasing.
/assign
/assign
/assign
/assign