jiebi/CodeConvo huggingface dataset:
Change:
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 is typo in Following is the text with a typo. kubeadm Proposed Solution: fix "" to "" Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Page link for reported issue: Markdown of glossary entry reported to have issue: /language ja
/area localization
/assign
/triage accepted

Discussion:
<!--more--> <del> kubeadmを使用して、コントロールプレーンとワーカーノード{{< glossary_tooltip text="ワーカーノード" term_id="node" >}}コンポーネントの両方をインストールできます。 </del> <ins> kubeadmを使用して、コントロールプレーンと{{< glossary_tooltip text="ワーカーノード" term_id="node" >}}コンポーネントの両方をインストールできます。 </ins>
Change:
This is a Feature Request What would you like to be Translate docs/concepts/policy/node-resource- into Japanese Why is this needed There is no Japanese translation for this page Comments File to translate: Original: /area localization /language ja /assign
/area localization /language ja /assign
404
/triage accepted

Discussion:
<ins> --- title: ノードリソースマネージャー content_type: concept weight: 50 --- <!-- overview --> レイテンシーが致命的なワークロードや高スループットのワークロードをサポートするために、Kubernetesは一連のリソースマネージャーを提供します。リソースマネージャーはCPUやデバイス、メモリ(hugepages)などのリソースの特定の要件が設定されたPodのためにノードリソースの調整と最適化を目指しています。 <!-- body --> メインのマネージャーであるトポロジーマネージャーは[ポリシー](/ja/docs/tasks/administer-cluster/topology-manager/)に沿って全体のリソース管理プロセスを調整するKubeletコンポーネントです。 個々のマネージャーの設定は下記のドキュメントで詳しく説明されてます。 - [CPUマネージャーポリシー](/docs/tasks/administer-cluster/cpu-management-policies/) - [デバイスポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) - [メモリマネージャーポリシー](/docs/tasks/administer-cluster/memory-manager/) </ins>
Change:
This is a Bug Report Problem: The minimum and default values for were removed after solving . Proposed Solution: Put the information back: Page to Update:
/sig docs
/assign
/triage accepted

Discussion:
Minimum value is 1. * `failureThreshold`: After a probe fails `failureThreshold` times in a row, Kubernetes considers that the overall check has failed: the container is _not_ ready/healthy/live. <ins> Defaults to 3. Minimum value is 1. </ins> For the case of a startup or liveness probe, if at least `failureThreshold` probes have failed, Kubernetes treats the container as unhealthy and triggers a restart for that specific container. The kubelet honors the setting of `terminationGracePeriodSeconds`
Change:
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 the , under redirects to a topic that has been removed in release 1.30 by this PR Therefore, the hyperlink no longer exists. was replaced with Proposed Solution: Replace this line in with this line and adding a hyperlink for Specifying Apparmor Confinement: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--If the suggested solution is okay. I can raise a PR for it.
/assign /sig node /language en /sig docs
/triage accepted /priority backlog

Discussion:
* `Localhost` to use a profile loaded on the host (see below) * `Unconfined` to run without AppArmor <del> See the [API Reference](#api-reference) for the full details on the AppArmor profile API. </del> <ins> See [Specifying AppArmor Confinement](#specifying-apparmor-confinement) for full details on the AppArmor profile API. </ins> To verify that the profile was applied, you can check that the container's root process is running with the correct profile by examining its proc attr:
Change:
This is a Feature Request What would you like to be In , the "author" metadata was to the front matter. Currently, some l10n teams are also setting "translator" metadata. This is one of the initiatives to promote the localization of blog posts. FYI: I would like to add "translator" metadata to the blog's front matter, just like the author metadata. Why is this needed To promote the localization of blog articles. This would be a significant motivation for those involved in localization. Comments
/area web-development /area blog /area localization
/assign
This is a great idea. It will be very motivating for localization contributors.
Thank you for your interest in this issue, mengjiao-liu ! I've opened a pull request to resolve it - . please have a look :)
Would be nice to add this feature. /priority backlog /triage accepted

Discussion:
[thirdparty_message_vendor] other = """Items on this page refer to vendors external to Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. To add a vendor, product or project to this list, read the <a href="/docs/contribute/style/content-guide/#third-party-content">content guide</a> before submitting a change. <a href="#third-party-content-disclaimer">More information.</a>""" <ins> [translated_by] other = "Translated By" </ins> [ui_search_placeholder] other = "Search this site"

<ins> <div class="td-content"> <h1>{{ .Title }}</h1> {{ with .Params.description }}<div class="lead">{{ . | markdownify }}</div>{{ end }} <div class="td-byline mb-4"> {{ with .Params.author }}{{ T "post_byline_by" }} <b>{{ . | markdownify }}</b> |{{ end}} {{ with .Params.translator }}{{ T "translated_by" }} <b>{{ . | markdownify }}</b> |{{ end }} <time datetime="{{  $.Date.Format "2006-01-02" }}" class="text-muted">{{ $.Date.Format $.Site.Params.time_format_blog  }}</time> </div> <header class="article-meta"> {{ partial "taxonomy_terms_article_wrapper.html" . }} {{ if (and (not .Params.hide_readingtime) (.Site.Params.ui.readingtime.enable)) }} {{ partial "reading-time.html" . }} {{ end }} </header> {{ .Content }} {{ if (.Site.Params.DisqusShortname) }} <br /> {{ partial "disqus-comment.html" . }} <br /> {{ end }} {{ partial "pager.html" . }} </div> </ins>
Change:
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 is typo at 177 lines in Proposed Solution: fix "" to "" Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ja /area localization /assign
/triage accepted

Discussion:
## static Pod <del> *static Pod*は、{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}には管理されない、特定のノード上でkubeletデーモンによって直接管理されるPodのことです。大部分のPodはコントロープレーン(たとえば{{< glossary_tooltip text="Deployment" term_id="deployment" >}})によって管理されますが、static Podの場合はkubeletが各static Podを直接管理します(障害時には再起動します)。 </del> <ins> *static Pod*は、{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}には管理されない、特定のノード上でkubeletデーモンによって直接管理されるPodのことです。大部分のPodはコントロールプレーン(たとえば{{< glossary_tooltip text="Deployment" term_id="deployment" >}})によって管理されますが、static Podの場合はkubeletが各static Podを直接管理します(障害時には再起動します)。 </ins> static Podは常に特定のノード上の1つの{{< glossary_tooltip term_id="kubelet" >}}に紐付けられます。static Podの主な用途は、セルフホストのコントロールプレーンを実行すること、言い換えると、kubeletを使用して個別の[コントロールプレーンコンポーネント](/ja/docs/concepts/overview/components/#control-plane-components)を管理することです。
Change:
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: On the production environment page, under the container runtimes section, there is a reference to from containerd as ongoing work. Proposed Solution: I think the reference should be removed or updated to this Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /triage accepted /priority backlog /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 : /language en /triage accepted /priority backlog 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 try to help with this. /assign

Discussion:
You might need to restart `containerd` as well once you've updated the config file: `systemctl restart containerd`. <del> Please note, that it is a best practice for kubelet to declare the matching `pod-infra-container-image`. If not configured, kubelet may attempt to garbage collect the `pause` image. There is ongoing work in [containerd to pin the pause image](https://github.com/containerd/containerd/issues/6352) and not require this setting on kubelet any longer. </del> ### CRI-O This section contains the necessary steps to install CRI-O as a container runtime.
Change:
This is a Bug Report The doc about finalizers doesn't give any information about the fact that the API server considers a deleted service account or a deleted pod's token invalid after 1 minute the DeletionTimestamp. ref: <!--Required Information--Problem: Proposed Solution: Document with a note. Page to Update: <!--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 en
/sig apps

Discussion:
When a bound token is presented to the kube-apiserver, the service account authenticator will extract and verify these claims. <ins> If the referenced object or the ServiceAccount is pending deletion (for example, due to finalizers), then for any instant that is 60 seconds (or more) after the `.metadata.deletionTimestamp` date, authentication with that token would fail. </ins> If the referenced object no longer exists (or its `metadata.uid` does not match), the request will not be authenticated.

[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use. <ins> The API credentials are automatically revoked when the Pod is deleted, even if finalizers are in place. In particular, the API credentials are revoked 60 seconds beyond the `.metadata.deletionTimestamp` set on the Pod (the deletion timestamp is typically the time that the **delete** request was accepted plus the Pod's termination grace period). </ins> ### Opt out of API credential automounting If you don't want the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}
Change:
This is a Bug Report There is a typo in the Chinese documentation. The text " kubectll " contains an extra "l" in "kubectl". Proposed Solution: The correct text should be " kubectl ". Page to Update:
/area localization /language zh
/triage accepted
/retitle Typo in localized page Kubernetes

Discussion:
* [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) * [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/) --> * [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) <del> * [为 kubectll 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) </del> <ins> * [为 kubectl 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) </ins> * [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) * [为上游 Kubernetes 项目做贡献以改进文档](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream/)
Change:
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

Discussion:
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
Change:
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 prerequisites for KMS encryption of control plane data are a bit stale given that KMSv2 is now fully stable and all supported releases include some level of KMSv2 support. no longer really applies. Proposed Solution: Revise and reword the start of the page, to focus on recommending KMSv2 rather than recommending specific Kubernetes versions. Page to Update: Additional Information: /sig security /language en
/priority backlog /triage accepted
/assign

Discussion:
The version of Kubernetes that you need depends on which KMS API version you have selected.  Kubernetes recommends using KMS v2. <del> - If you selected KMS API v2, you should use Kubernetes v{{< skew currentVersion >}} (if you are running a different version of Kubernetes that also supports the v2 KMS API, switch to the documentation for that version of Kubernetes). </del> - If you selected KMS API v1 to support clusters prior to version v1.27 or if you have a legacy KMS plugin that only supports KMS v1, any supported Kubernetes version will work.  This API is deprecated as of Kubernetes v1.28.
Change:
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.

Discussion:
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 ```
Change:
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: You cannot run to get a local website preview, nor can you run to build the container locally. Proposed Solution: Fix local previewing by ensuring that builds a working container image <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: This is relevant to contributor experience. Optionally, we could run CI tests whenever there is a change to , or , and verify that we can: build a container image run Hugo inside that image (smoke test)
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
I am unable to produce this because being blocked to , the command never worked for me (in China). I'm curious though what kind of errors we have encountered and why an upgrade of Go is required.
you can read more on this thread TLDR; the error was: ! Due to the latest Hugo upgrade that requires Golang 1.23 when building the image. The fix works locally: ! +1 to running a test in the CI. Would that be something completely new or a pre-existing pipeline to enhance? Asking because I don't see any other GitHub workflow aside from . Note: I'm still getting accustomed to the codebase so this question might sound silly._
Got it. A change to Go version is necessary.
To test the container image build locally, run . You need access to the Docker registry; you don't need access to push to Google.

Discussion:
# change is that the Hugo version is now an overridable argument rather than a fixed # environment variable. <del> FROM docker.io/library/golang:1.20-alpine </del> <ins> FROM docker.io/library/golang:1.23.0-alpine3.20 </ins> LABEL maintainer="Luc Perkins <lperkins@linuxfoundation.org>"

cd "hugo-${HUGO_VERSION}" &&  go install --tags extended <del> FROM docker.io/library/golang:1.20-alpine </del> <ins> FROM docker.io/library/golang:1.23.0-alpine3.20 </ins> RUN apk add --no-cache  runuser
Change:
Note that this issue is for Japanese Speaker This is a Feature Request What would you like to be Translate into Japanese Why is this needed There is no Japanese translation for this page Comments File to translate: Original: Japanese Localization document: /area localization /language ja /good-first-issue /triage accepted
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 : Note that this issue is for Japanese Speaker Original: /language ja /good-first-issue /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
/assign

Discussion:
<ins> --- title: FlexVolume id: flexvolume date: 2018-06-25 full_link: /ja/docs/concepts/storage/volumes/#flexvolume short_description: > FlexVolumeは、ツリー外のボリュームプラグインを作成するための非推奨なインターフェースです。{{< glossary_tooltip text="コンテナストレージインターフェース(CSI)" term_id="csi" >}}は、FlexVolumeのいくつかの問題に対処する新しいインターフェースです。 aka: tags: - storage --- FlexVolumeは、ツリー外のボリュームプラグインを作成するための非推奨なインターフェースです。{{< glossary_tooltip text="コンテナストレージインターフェース(CSI)" term_id="csi" >}}は、FlexVolumeのいくつかの問題に対処する新しいインターフェースです。 <!--more--> FlexVolumeを使用すると、ユーザーは独自のドライバーを作成し、Kubernetesでそれらのボリュームをサポートすることができます。 FlexVolumeドライバーのバイナリと依存関係は、ホストマシンにインストールする必要があります。 これにはrootアクセスが必要です。 Storage SIGは、FlexVolumeの制約に対処するために可能であれば{{< glossary_tooltip text="CSI" term_id="csi" >}}ドライバーを実装することを推奨しています。 * [KubernetesドキュメントのFlexVolume](/ja/docs/concepts/storage/volumes/#flexvolume) * [FlexVolumesの詳細な情報](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) * [ストレージベンダー向けボリュームプラグインに関するFAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) </ins>
Change:
Under , the hyper link is missing a "P" in "Plug-in". Corrected:
related page :
/language en
/kind bug
/assign
/triage accepted
Thanks

Discussion:
[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver) must be installed on the cluster. You can find additional advice on how to migrate in-tree `vsphereVolume` in VMware's documentation page <del> [Migrating In-Tree vSphere Volumes to vSphere Container Storage lug-in](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html). </del> <ins> [Migrating In-Tree vSphere Volumes to vSphere Container Storage Plug-in](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html). </ins> If vSphere CSI Driver is not installed volume operations can not be performed on the PV created with the in-tree `vsphereVolume` type. You must run vSphere 7.0u2 or later in order to migrate to the vSphere CSI driver.