jiebi/CodeConvo huggingface dataset:
Change:
/docs/tasks/administer-cluster/default-memory-request-limit/     /docs/tasks/configure-pod-container/assign-memory-resource/#specify-a-memory-request-and-a-memory-limit/ 301 /docs/tasks/administer-cluster/developing-cloud-controller-manager.md     /docs/tasks/administer-cluster/developing-cloud-controller-manager/ 301 /docs/tasks/administer-cluster/enabling-endpointslices/ /docs/concepts/services-networking/endpoint-slices/ 301 <ins> /docs/tasks/administer-cluster/highly-available-control-plane/    /docs/setup/production-environment/#production-control-plane 301 </ins> /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-13     /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ 301 /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-ha-1-13     /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ 301 /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-14     /docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ 301

Discussion:
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: In , and scripts are mentioned. But according to 's , And the in (where the and scripts exist) says that Proposed Solution: ~Update to not mention and scripts.~ Delete and redirect it to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/kind cleanup /triage accepted
/sig cluster-lifecycle (ish)
/reopen The page still mentions those scripts.
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
I think it would probably be best to instead drop all reference to them, we have if we need to document details to upstream contributors, previously we did not and sort of did double-duty IMHO
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]:
Let's delete and redirect it to /lifecycle frozen do you agree with that approach? If so, please update the issue description to highlight it as a plan.
→ Yes! → Done!
/assign
Thanks all.
Change:
{{ T "version_menu" }} </a> <div class="dropdown-menu dropdown-menu-right" aria-labelledby="navbarDropdownMenuLink"> <ins> {{ $p := . }} </ins> {{ range .Site.Params.versions }} <del> <a class="dropdown-item" href="{{ .url }}">{{ .version }}</a> </del> <ins> <a class="dropdown-item" href="{{ .url }}{{ $p.RelPermalink }}">{{ .version }}</a> </ins> {{ end }} </div>  No newline at end of file

Discussion:
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: Current page is lost when switching between documentation versions. Steps to reproduce to some page in the docs, for example the version selector at the top of the page to change to 1.17. that it it sends me to the instead of showing me the . Proposed Solution: Keep the relative path when switching versions Page to Update: All <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: Am I wrong that it used to preserve the page you are on when switching versions? I feel like it used to do that, but I'm not 100% sure.
Yes, at some point the site kept the same page when switching between versions.
/kind bug /priority backlog (I think this is a low-priority-backlog sort of issue; it's a frustration, but we have other places where it makes sense to focus effort first).
/area web-development
Change:
/docs/tasks/access-application-cluster/access-cluster.md     /docs/tasks/access-application-cluster/access-cluster/ 301! /docs/tasks/access-application-cluster/authenticate-across-clusters-kubeconfig/     /docs/tasks/access-application-cluster/configure-access-multiple-clusters/ 301 <del> /docs/tasks/access-kubernetes-api/access-kubernetes-api/custom-resources/custom-resource-definitions/     /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ 301 </del> <ins> /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/     /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ 301 </ins> /docs/tasks/access-kubernetes-api/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/     /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/ 301 /docs/tasks/access-kubernetes-api/access-kubernetes-api/http-proxy-access-api/     /docs/tasks/extend-kubernetes/http-proxy-access-api/ 301 /docs/tasks/access-kubernetes-api/configure-aggregation-layer/   /docs/tasks/extend-kubernetes/configure-aggregation-layer/ 301

Discussion:
This URL returns 404: The cause is an incorrect path in the responsible for redirecting it.
Change:
- If there are pods in one of these states _right after_ `kubeadm init`, please open an issue in the kubeadm repo. `coredns` (or `kube-dns`) should be in the `Pending` state <del> until you have deployed the network solution. </del> <ins> until you have deployed the network add-on. </ins> - If you see Pods in the `RunContainerError`, `CrashLoopBackOff` or `Error` state <del> after deploying the network solution and nothing happens to `coredns` (or `kube-dns`), it's very likely that the Pod Network solution that you installed is somehow broken. </del> <ins> after deploying the network add-on and nothing happens to `coredns` (or `kube-dns`), it's very likely that the Pod Network add-on that you installed is somehow broken. </ins> You might have to grant it more RBAC privileges or use a newer version. Please file an issue in the Pod Network providers' issue tracker and get the issue triaged there. - If you install a version of Docker older than 1.12.1, remove the `MountFlags=slave` option

Discussion:
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: There are words should be unified in and . For the sake of clarity, the same words should be used for things that have the same meaning. Proposed Solution: We should use either the terms "network solution" or "network add-on". Page to Update: Troubleshooting kubeadm: Installing Addons: <!--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
modifying the kubeadm troubleshooting page to use "addon" instead of "solution" seems fine to me. PRs welcome! /help /sig cluster-lifecycle /kind cleanup /priority backlog
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 : modifying the kubeadm troubleshooting page to use "addon" instead of "solution" seems fine to me. PRs welcome! /sig cluster-lifecycle /kind cleanup /priority backlog </details
/assign
/assign
Change:
``` deployment.apps/nginx-deployment resumed ``` <del> * Watch the status of the rollout until it's done. </del> <ins> * {{< glossary_tooltip text="Watch" term_id="watch" >}} the status of the rollout until it's done. </ins> ```shell <del> kubectl get rs -w </del> <ins> kubectl get rs --watch </ins> ``` The output is similar to this:

Discussion:
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 the to include an explanation of “watch”. Why is this needed The watch verb (and actually watchcollection as well) is K8s-specific jargon. We should help readers understand it. Comments Extra credit for also using the new term in existing pages, using a . /kind feature /wg api-expression
/assign
/priority backlog /triage accepted
Hi PR: for this issue. PTAL
I'm happy for any reviewer (for English) to take a look there.
Change:
Bring the node back online by marking it schedulable: ```shell <ins> # execute this command on a control plane node </ins> # replace <node-to-uncordon> with the name of your node kubectl uncordon <node-to-uncordon> ```

Discussion:
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: This is related to the page . The and commands should be executed on the controlplane node. This is not obvious from the documentation. A new user unfamiliar with the process of upgrade will invariably execute these commands on the worker node and will fail. Proposed Solution: Add instruction to execute the and commands from the controlplane node. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
/sig docs /language en
/sig cluster-lifecycle /triage accepted
Change:
peerCertSANs: - "${HOST}" extraArgs: <del> initial-cluster: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380 initial-cluster-state: new name: ${NAME} listen-peer-urls: https://${HOST}:2380 listen-client-urls: https://${HOST}:2379 advertise-client-urls: https://${HOST}:2379 initial-advertise-peer-urls: https://${HOST}:2380 </del> <ins> - name: initial-cluster value: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380 - name: initial-cluster-state value: new - name: name value: ${NAME} - name: listen-peer-urls value: https://${HOST}:2380 - name: listen-client-urls value: https://${HOST}:2379 - name: advertise-client-urls value: https://${HOST}:2379 - name: initial-advertise-peer-urls value: https://${HOST}:2380 </ins> EOF done ```

Discussion:
The kubeadm config snippet uses the v1beta3 that is a , in this seems to be a .
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
Actually, that is how the API changed. See for source code, and for an example. /close
Closing this issue. <detailsIn response to : Actually, that is how the API changed. See for source code, and for an example. /close </details
Yes, the API has been updated and the docs need to be updated to reflect that. I apologize, my initial report was lazy. Let me try again. When using the configuration in to create a HA etcd cluster, it fails due to being unable to marshal into . This is because the API has been updated in v1beta4 and is no longer a . You'll notice in the sample, the is , however the structure of is still a map. This was correct for , but is no longer correct for . I've opened a PR to rectify this.
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
Got it. Let's reopen this issue and let it be fixed by your PR.
Change:
You can specify scheduling profiles by running `kube-scheduler --config <filename>`, using the component config APIs <del> ([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration) or [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration)). The `v1alpha2` API allows you to configure kube-scheduler to run [multiple profiles](#multiple-profiles). </del> <ins> ([`v1beta1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.19.0/config/v1beta1?tab=doc#KubeSchedulerConfiguration)). </ins> A minimal configuration looks as follows:

Discussion:
I found the references to and v1alpha2 to be confusing since the configuration that follow were v1beta1. Perhaps it would make sense to remove the alpha1/2 references entirely? !
Change:
Adding these tolerations ensures backward compatibility. You can also add arbitrary tolerations to DaemonSets. ## {{% heading "whatsnext" %}} * Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it

Discussion:
Page to update: Blocked by Based on in PR , we should add the following information about node conditions to the Taint Nodes by Condition section of this page. The API server also respects when making scheduling decisions. For example, If the node condition is active, the system doesn't allow any new Pods to schedule on the node. If the node condition is active on a node, the system doesn't allow new pods on the node. What is "the system"? The API server? /cc /assign /sig docs /language en
"The system" is a mix of components: the kube-controller-manager sets the taints via the node controller. apiserver sets the toleration for DiskPressure for non-BestEffort pods. scheduler checks if pods have tolerations for the taint But that's too much implementation detail. "The system" or "the control plane" should be enough. WDYT ?
Ah, if it's the control plane then we can say that haha I thought it was something else :P
/triage accepted
Change:
Kubernetes 1.20で[dockershim deprecation](blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)が発表されてから、様々なワークロードやKubernetesインストールにどう影響するのかという質問が寄せられています。 <del> この問題をよりよく理解するために、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)ブログが役に立つでしょう。 </del> <ins> この問題をよりよく理解するために、[dockershimの削除に関するFAQ](/ja/dockershim)ブログが役に立つでしょう。 </ins> dockershimから代替のコンテナランタイムに移行することが推奨されます。 [コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)のセクションをチェックして、どのような選択肢があるかを確認してください。

Discussion:
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. --Add japanese translations of the contents listed below: {{% dockershim-removal %}} block Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --ref.
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
/language ja
Change:
{{< tabs name="kubectl_retainkeys_example" >}} {{{< tab name="Bash" codelang="bash" >}} <del> kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)" </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)" </ins> {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} <del> kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </ins> {{< /tab >}}} {{< /tabs >}}

Discussion:
example commands are missing Resulting in: I will prepare a patch for this.
/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 : /triage accepted /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
個々のアプリケーションコンテナと同様に、Podは(永続的ではなく)比較的短期間の存在と捉えられます。Podが作成されると、一意のID([UID](/ja/docs/concepts/overview/working-with-objects/names/#uids))が割り当てられ、(再起動ポリシーに従って)終了または削除されるまでNodeで実行されるようにスケジュールされます。 {{< glossary_tooltip term_id="node" >}}が停止した場合、そのNodeにスケジュールされたPodは、タイムアウト時間の経過後に[削除](#pod-garbage-collection)されます。 <del> Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗、またはスケジュール操作自体が失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりPodはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 </del> <ins> Pod自体は、自己修復しません。Podが{{< glossary_tooltip text="node" term_id="node" >}}にスケジュールされ、その後に失敗した場合、Podは削除されます。同様に、リソースの不足またはNodeのメンテナンスによりPodはNodeから立ち退きます。Kubernetesは、比較的使い捨てのPodインスタンスの管理作業を処理する、{{< glossary_tooltip term_id="controller" text="controller" >}}と呼ばれる上位レベルの抽象化を使用します。 </ins> 特定のPod(UIDで定義)は新しいNodeに"再スケジュール"されません。代わりに、必要に応じて同じ名前で、新しいUIDを持つ同一のPodに置き換えることができます。 {{< glossary_tooltip term_id="volume" text="volume" >}}など、Podと同じ存続期間を持つものがあると言われる場合、それは(そのUIDを持つ)Podが存在する限り存在することを意味します。そのPodが何らかの理由で削除された場合、たとえ同じ代替物が作成されたとしても、関連するもの(例えばボリューム)も同様に破壊されて再作成されます。 <del> {{< figure src="/images/docs/pod.svg" title="Podの図" width="50%" >}} </del> <ins> {{< figure src="/images/docs/pod.svg" title="Podの図" class="diagram-medium" >}} </ins> *file puller(ファイル取得コンテナ)とWebサーバーを含むマルチコンテナのPod。コンテナ間の共有ストレージとして永続ボリュームを使用しています。*

Discussion:
This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/workloads/pods/pod- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/workloads/pods/pod- is outdated. For example, there is no description of PodHasNetwork(alpha feature). Comments /language ja /assign
/triage accepted
Change:
} } <del> body > footer { width: 100vw; } </del> /* FOOTER */ footer { background-color: #303030;

Discussion:
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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26
Change:
Some cloud providers require a config file. If so, you need to put config file into apiserver image or mount through hostPath. - `--cloud-config=` set if cloud provider requires a config file. <del> - Used by `aws`, `gce`, `mesos`, `openshift`, `ovirt` and `rackspace`. </del> <ins> - Used by `aws`, `gce`, `mesos`, `openstack`, `ovirt` and `rackspace`. </ins> - You must put config file into apiserver image or mount through hostPath. - Cloud config file syntax is [Gcfg](https://code.google.com/p/gcfg/). - AWS format defined by type [AWSCloudConfig](https://releases.k8s.io/{{page.githubbranch}}/pkg/cloudprovider/providers/aws/aws.go)

Discussion:
<!-- 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: At "Cloud Providers" paragraph, There is a sentence following. In this sentence, is "openshift" correct? It should be "openstack", I think. Because following sentence is described at same paragraph. Here, "openshift" isn't present, but "openstack" is present. Proposed Solution: Replace "openshift" with "openstack" in sentence at "Cloud Providers" paragraph following. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
thanks - I suspect you're correct and made a quick patch () to resolve. When I looked in the cloud-provider releases for 1.8, there was one for openstack, but not openshift - so I think this was just a missed typo/reference mistake