jiebi/CodeConvo huggingface dataset:
Code change:
Talking to the control-plane node with the appropriate credentials, run: ```bash <del> kubectl drain <node name> --delete-local-data --force --ignore-daemonsets </del> <ins> kubectl drain <node name> --delete-emptydir-data --force --ignore-daemonsets </ins> ``` Before removing the node, reset the state installed by `kubeadm`:

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: Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. Proposed Solution: Update to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/sig cluster-lifecycle
cc
i see the discussion / PR here: using in the kubeadm docs makes sense. /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 : Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. /help </details
/assign
Code change:
* `apiserver_flowcontrol_request_queue_length_after_enqueue` is a histogram vector of queue lengths for the queues, broken down by <del> the labels `priorityLevel` and `flowSchema`, as sampled by the </del> <ins> the labels `priority_level` and `flow_schema`, as sampled by the </ins> enqueued requests.  Each request that gets queued contributes one sample to its histogram, reporting the length of the queue just after the request was added.  Note that this produces different

Related discussion:
text: Keep the doc consistent with
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:
## Constraints <del> * Topology Aware Hints are not used when either `externalTrafficPolicy` or `internalTrafficPolicy` is set to `Local` on a Service. It is possible to use both features in the same cluster on different Services, just not on the same Service. </del> <ins> * Topology Aware Hints are not used when `internalTrafficPolicy` is set to `Local` on a Service. It is possible to use both features in the same cluster on different Services, just not on the same Service. </ins> * This approach will not work well for Services that have a large proportion of traffic originating from a subset of zones. Instead this assumes that incoming

Related discussion:
text: The existing documentation for Topology Aware Routing says however, this was before refactored and fixed the kube-proxy traffic policy problems caused by the lack of definitions on the Service traffic types This caused issues like fixed with , because we have mixed mode, If I understand correctly, right now and are not exclusive, since the former applies the traffic that is originated from "outside the cluster" and the later only applies to the traffic originated within the cluster. If that is correct , we should modify the documentation to say "Topology Aware Hints are not used when internalTrafficPolicy is set to Local on a Service. It is possible to use both features in the same cluster on different Services, just not on the same Service."
/assign /sig network
/retitle Stale docs for topology aware routing constraints
/language en
Thanks for catching this Agree with your proposed fix.
/triage accepted /kind bug
/assign
Code change:
Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) wget: download timed out / #

Related discussion:
text: <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [X] Bug Report Problem: The link "build-tools/" doesn't work anymore and returns 404. Proposed Solution: Fix the link Page to Update:
Fixed. Thanks!
Code change:
Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) wget: download timed out / #

Related discussion:
text: <!-- 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: Page url: in line 83, click PetSets guide occur 404 error. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Fixed.
Code change:
Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) wget: download timed out / #

Related discussion:
text: This is a... [ ] Feature Request [X] Bug Report Problem: link "Minikube installation guide" points to which is 404 Proposed Solution: fix the link by making it absolute: Page to Update:
Fixed.
Code change:
Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) wget: download timed out / #

Related discussion:
text: <!-- 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: Multiple links on the page generate 404 Not Found Examples: (redirected from ) (redirected from ) Proposed Solution: fix the links Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Here is the full list of broken links on xhyve driver kvm (driver installation) xhyve (driver installation) See DRIVERS docker-env command minikube start minikube stop minikube delete full CLI docs
Code change:
Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) wget: download timed out / #

Related discussion:
text: I wish /docs/user-guide/horizontal-pod-autoscaling/walkthrough/ actually contained the information, or at least a link to autoscaling by custom application logic (as referred to by the first sentence in the article - . The second half of this article seems like the correct target link -
Fixed. Thanks.
Code change:
sudo sysctl --system ``` <del> Make sure that the `br_netfilter` module is loaded before this step. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. </del> For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. ## Check required ports

Related discussion:
text: This paragraph is a bit backwards. It would be more intuitive to start with the "Make sure that the br_netfilter module is loaded before this step..." phrases.
/language en /kind cleanup /priority backlog /good-first-issue Thanks
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 : /language en /kind cleanup /priority backlog /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
/sig cluster-lifecycle
Code change:
- containerPort: 80 ``` <del> ### Deployment with kubeadm and cluster API </del> <ins> ### kubeadmとクラスターAPIを使用したデプロイ </ins> <del> Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm will come in a future release. We are also making investments in cluster API to ensure Windows nodes are properly provisioned. </del> <ins> Kubeadmは、ユーザーがKubernetesクラスターをデプロイするための事実上の標準になりつつあります。kubeadmのWindowsノードのサポートは、将来のリリースで提供予定です。Windowsノードが適切にプロビジョニングされるように、クラスターAPIにも投資しています。 </ins> <del> ### A few other key features * Beta support for Group Managed Service Accounts * More CNIs * More Storage Plugins </del> <ins> ### その他の主な機能 * グループ管理サービスアカウントのベータサポート * その他のCNI * その他のストレージプラグイン </ins>

Related discussion:
text: This is a Feature Request What would you like to be Translate docs/setup/production-environment/windows/intro-windows-in-kubernetes/ into Japanese Why is this needed This page has not been translated. Comments /language ja /assign
/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:
#### Configure and start the Kubernetes cluster The startup process will first download all the required binaries automatically. <del> By default etcd version is 2.2.1, flannel version is 0.5.5 and k8s version is 1.1.4. </del> <ins> By default etcd version is 2.2.1, flannel version is 0.5.5 and k8s version is 1.1.8. </ins> You can customize your etcd version, flannel version, k8s version by changing corresponding variables `ETCD_VERSION` , `FLANNEL_VERSION` and `KUBE_VERSION` like following. ```shell <del> $ export KUBE_VERSION=1.0.5 </del> <ins> $ export KUBE_VERSION=1.1.8 </ins> $ export FLANNEL_VERSION=0.5.0 $ export ETCD_VERSION=2.2.0 ```

Related discussion:
text: The script actually defaults to k8s version 1.1.8, but the docs says it is 1.1.4
Thank you for the PR, Mike!
Code change:
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" #  A list of additional security groups to be added to the created ELB, this leaves the uniquely generated security group in place, this ensures that every ELB # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes (service traffic and health checks). <del> # Security groups defined here can be shared between services. </del> <ins> # Security groups defined here can be shared between services. </ins> service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" # A comma separated list of key-value pairs which are used

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: 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
Code change:
为客户提供无缝的服务。 <!-- <del> ## Enabling API groups </del> <ins> ## Enabling or disabling API groups </ins> Certain resources and API groups are enabled by default.  They can be enabled or disabled by setting `--runtime-config` <del> on apiserver. `--runtime-config` accepts comma separated values. For ex: to disable batch/v1, set </del> <ins> on apiserver. `--runtime-config` accepts comma separated values. For example: to disable batch/v1, set </ins> `--runtime-config=batch/v1=false`, to enable batch/v2alpha1, set `--runtime-config=batch/v2alpha1`. The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver. <del> IMPORTANT: Enabling or disabling groups or resources requires restarting apiserver and controller-manager </del> <ins> Enabling or disabling groups or resources requires restarting apiserver and controller-manager </ins> to pick up the `--runtime-config` changes. -->

Related discussion:
text: This is a Feature Request Since v1.16, extensions/v1beta1 has been deleted and it should not be used in docs What would you like to be The following pages should be edited due to this deletion. [ ] [ ] [x] [ ] [ ] [ ] [ ] [ ] [x] [x] Why is this needed extensions/v1beta1 is deleted in 1.16 Comments
/kind cleanup /priority important-soon (I think)
If you are looking at this as potentially something to contribute to, it's OK to suggest a PR that fixes only one page, or only some pages. If you do that please mention “Partial fix for issue ” in the description of your PR.
thanks for contribution here. Could you please share which pages would you take? Let us make the assignment more clear and help other contributors easily start their work.
Thank you for your comments. I wrote the target file into PR titles. And I will write to the comment about netlify demo pages and original pages to enable checking the diff easily.
Code change:
<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress spec: podSelector: {} policyTypes: - Ingress </ins>

Related discussion:
text: This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
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
Code change:
weight: 40 --> <ins> {{< feature-state for_k8s_version="v1.19" state="stable" >}} <!-- leave this shortcode in place until the note about EvenPodsSpread is obsolete --> </ins> <!-- overview --> <!--

Related discussion:
text: <!-- 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: [zh] Need trans for <!--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
/language zh
/assign
Code change:
<!-- overview --> <del> This document catalogs the communication paths between the API server and the Kubernetes cluster. </del> <ins> This document catalogs the communication paths between the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} and the Kubernetes {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}. </ins> The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).

Related discussion:
text: This is a Feature Request What would you like to be There are terms that can use the addition of a glossary tooltip to show the meaning of the said term. There is no or reference section Some terms can use references like : , Why is this needed Rather than searching for the definitions of some terms , the references can help understanding the concept while staying on same page or finding more about the concept with right link. it will enhance user experience and bring more clarity and less confusion. Comments The page needed to be updated here 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
/kind feature /language en /sig docs
If the triage is accepted would be happy to contribute references I have searched while reading the concept. /assign
Worth doing, but the change I outline in is more valuable to work on.
here seems to be about the and page in particular. I'd agree with the general idea of making the content brief and putting extra information in the reference. For control-plane-node-communication page, I see your comment about adding a diagram there. Will try to add that as well.
For now, I'll push this commit, in case even if we shift this content to reference or another section, we would still need some of the links and references.
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]:
/remove-lifecycle stale
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 Linux Worker 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 Linux Worker 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