jiebi/CodeConvo huggingface dataset:
Code change:
```shell kubectl get -f myapp.yaml ``` <ins> 実行結果は下記のようになります。 </ins> ``` NAME        READY     STATUS     RESTARTS   AGE myapp-pod   0/1       Init:0/2   0          6m

Related discussion:
text: 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. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. 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
Code change:
## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs-node-upgrade.md" >}} {{< version-check >}} </ins> * Familiarize yourself with [the process for upgrading the rest of your kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to upgrade the control plane nodes before upgrading your Windows nodes.

Related discussion:
text: Missing important step new people SSH into the node
/language en
Hi could you please explain the issue in detail. /triage needs-information
Page mentioned in the issue (based on the title): /language en
/retitle Users not instructed to SSH into the node before executing commands in "Upgrading Linux nodes" page
/sig cluster-lifecycle
I'm not sure this is valid, though there isn't much detail to the issue to explain what the concern is. The commands on that page need to be run on the node being upgraded, but I think how the administrator connects to that node is out of scope. It may be SSH, it may be by accessing the cloud providers console. It may be by rolling up a crash cart and plugging in a monitor and keyboard. That all depends on the individuals environment.
/remove-triage needs-information
/remove-kind support /priority awaiting-more-evidence /kind feature /sig cluster-lifecycle
Those labels are not set on the issue: <detailsIn response to : /remove-kind support /priority awaiting-more-evidence /kind feature /sig cluster-lifecycle 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
My opinion: if you (the reader) don't know how to get a shell on a node, it may not be a good idea to try upgrading it. Best learn the basics first.
We could list “shell access to the node“ as a prerequisite. I don't think we can or should assume SSH; I'm barely happy that we assume superuser access comes via .
for new contributors. page to update: change: to: make sure you add in the PR description. /help /triage accepted
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.
Code change:
## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs-node-upgrade.md" >}} {{< version-check >}} </ins> * Familiarize yourself with [the process for upgrading the rest of your kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade). You will want to upgrade the control plane nodes before upgrading your Windows nodes.

Related discussion:
text: If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : for new contributors. You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster You need to have a Kubernetes cluster, shell access to all its nodes, and the kubectl command-line tool must be configured to communicate with your cluster /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind feature /remove-priority awaiting-more-evidence
/priority backlog
This one looks like a candidate for a "good first issue" label. I think that the page should also have the shell access note, regardless of the method used (ssh, rdp, etc).
I don't think this is a good first issue. A good first issue would have a description that helped totally new contributors find out how to help, and the description for this issue at the time of writing is:
/assign
Got it. Going through the details, I see another problem here. The pre-req of having shell access to the nodes seems mostly relevant (a corner case) for the node upgrade task, for other cluster maintenance tasks, API access to node management seems enough. The problem is that the , and many other pages use the same prerequisites document (). So, adding the "get shell access to the nodes" phrase will alter all these documents where this step is not needed. I think that, for this particular task, we should not use the include prerequisite doc and rewrite the paragraph locally on the pages, as a compromise between convenience and accuracy. What do you think?
That'll work fine.
Given the need to modify two documents and the potential for content drift across releases, etc, I decided to add a new prereqs include file with the modified paragraph instead of rewriting the whole prerequisites section on both documents. Let me know what you think. Thanks
Code change:
### Weave Net from Weaveworks <del> [Weave Net](https://www.weave.works/products/weave-net/) is a </del> <ins> [Weave Net](https://www.weave.works/oss/net/) is a </ins> resilient and simple to use network for Kubernetes and its hosted applications. Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/) or stand-alone.  In either version, it doesn't require any configuration or extra code

Related discussion:
text: 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. --In , update the link URL from to update the link URL from to update the link URL from to update the link URL from to update the link URL from to update the link URL from to Why is this needed redirects to , which is a fork of and currently 62 commits behind . The latest commit of : on 29 Oct 2021 The latest commit of : on 12 Feb 2019 and for other CNIs, it would be better to use the final URLs than using redirecting URLs. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Page to update:
/assign
/triage accepted /kind cleanup
/retitle Fix incorrect / outdated URIs in list of network plugins /language en /priority backlog
Code change:
from the community. Please try it out and give us feedback! {{< /caution >}} <ins> ## kubeadm alpha certs {#cmd-certs} A collection of operations for operating Kubernetes certificates. {{< tabs name="tab-certs" >}} {{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs renew {#cmd-certs-renew} You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.

Related discussion:
text: This is a Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected.
Code change:
from the community. Please try it out and give us feedback! {{< /caution >}} <ins> ## kubeadm alpha certs {#cmd-certs} A collection of operations for operating Kubernetes certificates. {{< tabs name="tab-certs" >}} {{< tab name="overview" include="generated/kubeadm_alpha_certs.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs renew {#cmd-certs-renew} You can renew all Kubernetes certificates using the `all` subcommand or renew them selectively.

Related discussion:
text: So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks
Code change:
known endpoints. To use different container runtime or if there are more than one installed on the provisioned node, specify the `--cri-socket` argument to `kubeadm`. See [Installing a runtime](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). <del> 1. (Optional) Unless otherwise specified, `kubeadm` uses the network interface associated with the default gateway to set the advertise address for this particular control-plane node's API server. To use a different network interface, specify the `--apiserver-advertise-address=<ip-address>` argument to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you must specify an IPv6 address, for example `--apiserver-advertise-address=2001:db8::101` </del> To initialize the control-plane node run:

Related discussion:
text: I have a catastrophic problem with my production control-plane just because I naive believe in the instruction of the output of . My control-plane was gone and I couldn't recover from the failure because could not restart. After some tests, I found that need to be so that it tell the to use the correct internal IP that allow both new control plane and the current plane to talk to each other. Specifically, those IPs should allow etcd to communicate throw both servers. Without the default IP interface was used, but the firewall that I set on the default IP did not allow etcd to connect through. At this point, I would like to make a change to the document in a way that it emphasize the importance of in the command.
/language en /sig docs /kind feature
Page reported in issue: /sig cluster-lifecycle
/retitle Highlight the significance of in kubeadm join for HA cluster setup
all k8s components work like that. not only kubeadm. if you want custom IP from a different interface you need to pass it to the advertise address flag, but also as --node-ip to the kubelet. overall this setup with private IPs is not recommended and is difficult to manage. instead you should make the setup so that the public IP is the default route. then firewall the cluster properly. PRs for the above "create cluster" page with a note fix are welcome. the note can talk about "init" and "join", public IPs and firewall. /help /sig network
/triage accepted
actually, let me try to send the note. /remove-help
/assign
Code change:
### rbd `rbd` 볼륨을 사용하면 <del> [Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)(RBD) 볼륨을 파드에 마운트할 수 </del> <ins> [Rados Block Device](https://docs.ceph.com/en/latest/rbd/)(RBD) 볼륨을 파드에 마운트할 수 </ins> 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를

Related discussion:
text: doc address: The link address is invalid after the field is clicked, return http code 404  SORRY /  /  This page does / ] not exist yet. [ ,'| ] [ / | ] [ ,' | ] ] /[ [ ] ]  / [ [ ] ] ] [ [ [ ] ] ] [ [ [ ] ] ] ] /[ [ [ [ ] ] ] ] (#) [ [ [ [ :====' ] ] ]].nHn.[_[ [ [ ] ] ] HHHHH. [ [ [ ] ] / `HH("N  [ [ ]]/ HHH " [[ ] NNN [ ] N/" [ ] N H [ / N  / q,  / 
/assign
/kind bug /sig storage /priority backlog /language en /triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
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-contributor-experience at . /lifecycle stale
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Code change:
The Kubernetes project uses an automation tool called prow for automation related to GitHub issues and pull requests. The [Kubernetes website repository](https://github.com/kubernetes/website) uses <del> two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): </del> <ins> two [prow plugins](https://github.com/kubernetes-sigs/prow/tree/main/pkg/plugins): </ins> - blunderbuss - approve

Related discussion:
text: This is bug report Due to the prow source code was moved along with ghProxy to the repository on April 9, 2024 so there is invalid link in for . Problem In this , which is redirecting to the invalid page Solution Give the right path location for
Page to update
/sig docs /language en
I will raised PR for this. /assign
/kind bug
/priority backlog /triage accepted
Code change:
--- title: Service Accounts description: > <del> Learn about the Kubernetes ServiceAccount object. </del> <ins> Learn about ServiceAccount objects in Kubernetes. </ins> content_type: concept weight: 10 ---

Related discussion:
text: No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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]:
/remove-lifecycle stale
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.
Code change:
* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: <del> ```shell kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 ``` </del> <ins> ```shell kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1 ``` </ins> * `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.

Related discussion:
text: 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: line 35~39, there are extra spaces(more than 4 spaces) in front of shell box. line 427~430, it should be a shell box. So, we need shell code. line 445~451, it should be a shell box. So, we need shell code. Proposed Solution: [1] : Specifies the . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: [2] [3] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign
Code change:
[plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: <del> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume-deprecated) </del> <ins> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume) </ins> * Please note that FlexVolumes have been deprecated as of 1.23 * [`CSI Plugins`](/docs/concepts/storage/volumes/#csi)

Related discussion:
text: 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
/triage accepted
Code change:
[plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: <del> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume-deprecated) </del> <ins> * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume) </ins> * Please note that FlexVolumes have been deprecated as of 1.23 * [`CSI Plugins`](/docs/concepts/storage/volumes/#csi)

Related discussion:
text: 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