jiebi/CodeConvo huggingface dataset:
Change:
## Using the `cgroupfs` driver <del> As this guide explains using the `cgroupfs` driver with kubeadm is not recommended. To continue using `cgroupfs` and to prevent `kubeadm upgrade` from modifying the </del> <ins> To use `cgroupfs` and to prevent `kubeadm upgrade` from modifying the </ins> `KubeletConfiguration` cgroup driver on existing setups, you must be explicit about its value. This applies to a case where you do not wish future versions of kubeadm to apply the `systemd` driver by default.

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: The following sentence is not complete: As this guide explains using the cgroupfs driver with kubeadm is not recommended. What would you like to be : More information needs to be after "explains", or rephrase it from scratch. 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
/language en /sig cluster-lifecycle
do you mean that the sentence: As this guide explains using the cgroupfs driver with kubeadm is not recommended. should link to one of the earlier paragraphs on the same page (same guide)? The page explains that the systemd driver is recommended for kubeadm based setups instead of the cgroupfs driver, because kubeadm manages the kubelet as a systemd service. if you have a particular change in mind, please send a PR for review.
technically, as per the overall page context, the sentence: As this guide explains using the cgroupfs driver with kubeadm is not recommended. can be deleted entirely... the section is providing an alternative after the main point has been made earlier - i.e. "cgroupfs driver = not recommended".
Change:
section.k8s-birthday-override:has(div.k8s-birthday-override.revert-to-previous input:not(:checked)) + section { display: none; visibility: hidden; <ins> } /* Apply site-wide table styles for tables in alert callouts (note, caution, warning) */ .alert { &.alert-info, &.alert-caution, &.alert-danger { > table { @extend .table-striped; @extend .table-responsive; @extend .table; } } </ins> }  No newline at end of file

Discussion:
Problem: ! Proposed Solution: I have no idea because I have never used Hugo Page to Update:
/area web-development /triage accepted
Can I take care of it?
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
It is not clear what is the next step to take this issue to closure. I see tried a number of things in Is the issue that the table "borders" are not rendered correctly in the Note admonition? It seems Hugo is not able to render the borders of the table when it is inside a Note admonition block. In this case it should be reported as a bug to Hugo, right? In the meanwhile, I propose we remove the part of having support for a table inside a Note from the Propose to remove from the below section. !
I have raised a for support in the Hugo forums.
There is an answer on the Hugo forum stating that this is not a Hugo issue. The suggestion is to fix the CSS. Any pointers?
Change:
There are two special cases: <del> * An empty `key` with operator `Exists` matches all keys, values and effects which means this </del> <ins> An empty `key` with operator `Exists` matches all keys, values and effects which means this </ins> will tolerate everything. <del> ```yaml tolerations: - operator: "Exists" ``` * An empty `effect` matches all effects with key `key`. ```yaml tolerations: - key: "key" operator: "Exists" ``` </del> <ins> An empty `effect` matches all effects with key `key`. </ins> {{< /note >}}

Discussion:
This is a Bug Report Problem: The document is not rendered correctly: ! Proposed Solution: In-lining this special cases text by removing the call-out seems reasonable? Page to Update:
This is related to tracking issue . The long term fix is probably along the lines of For a work-around, how about rewording the note so that it remains called out but does not use a bulleted list? /kind bug /language en
Change:
## Support for ThirdPartyResources As of Kubernetes 1.5, ThirdPartyResources are not supported by `kubectl apply`. <del> The recommended approach for ThirdPartyResources is to use [imperative object configuration](/docs/concepts/tools/kubectl/object-management-using-imperative-config/). </del> <ins> The recommended approach for ThirdPartyResources is to use [imperative object configuration](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/). </ins> {% endcapture %} {% capture whatsnext %}

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: 404 on Proposed Solution: Update location of Page to Update:
Change:
```shell # Label your nodes with the accelerator type they have. <del> kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80 kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100 </del> <ins> kubectl label nodes node1 accelerator=example-gpu-x100 kubectl label nodes node2 accelerator=other-gpu-k915 </ins> ``` <ins> That label key `accelerator` is just an example; you can use a different label key if you prefer. </ins> ## Automatic node labelling {#node-labeller} If you're using AMD GPU devices, you can deploy

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: doesn't have our disclaimer for 3rd party content. Proposed Solution: Add a third party content disclaimer. See for an example. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /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. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: doesn't have our disclaimer for 3rd party content. Add a third party content disclaimer. See for an example. <!--Kubernetes Version:--/language en /help /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
Separately, it would be good if didn't include advice about installing the plugins. Instead, we can hyperlink to the vendors' own docs (where those exist).
Change:
### フックハンドラーの実行 コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはフックアクションにしたがってハンドラーを実行します。 <del> `exec`と`tcpSocket`はコンテナの中で実行され、`httpGet`はkubeletプロセスによって実行されます。 </del> <ins> `httpGet`と`tcpSocket`はkubeletプロセスによって実行され、`exec`はコンテナの中で実行されます。 </ins> フックハンドラーの呼び出しは、コンテナを含むPodのコンテキスト内で同期しています。 これは、`PostStart`フックの場合、コンテナのENTRYPOINTとフックは非同期に起動することを意味します。 しかし、フックの実行に時間がかかりすぎたりハングしたりすると、コンテナは`running`状態になることができません。 <del> `PreStop`フックはコンテナを停止する信号から非同期で実行されるのではなく、信号が送られる前に実行を完了する必要があります。 </del> <ins> `PreStop`フックはコンテナを停止するシグナルから非同期で実行されるのではなく、TERMシグナルが送られる前に実行を完了する必要があります。 </ins> もし`PreStop`フックが実行中にハングした場合、Podは`Terminating`状態になり、 `terminationGracePeriodSeconds`の時間切れで強制終了されるまで続きます。 この猶予時間は、`PreStop`フックが実行され正常にコンテナを停止できるまでの合計時間に適用されます。 <del> 例えば`terminationGracePeriodSeconds`が60で、フックの終了に55秒かかり、シグナルを受信した後にコンテナを正常に停止させるのに10秒かかる場合、コンテナは正常に停止する前に終了されてしまいます。`terminationGracePeriodSeconds`が、これら２つの実行にかかる合計時間(55+10)よりも短いからです。 </del> <ins> 例えば`terminationGracePeriodSeconds`が60で、フックの終了に55秒かかり、シグナルを受信した後にコンテナを正常に停止させるのに10秒かかる場合、コンテナは正常に停止する前に終了されてしまいます。`terminationGracePeriodSeconds`が、これら2つの実行にかかる合計時間(55+10)よりも短いからです。 </ins> `PostStart`または`PreStop`フックが失敗した場合、コンテナは強制終了します。

Discussion:
This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/containers/container-lifecycle- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/containers/container-lifecycle- is outdated. Comments /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
Change:
経験の多寡や難易度にかかわらず、どんなことでも質問してください。我々の目標は、全ての人が将来の変化について、可能な限りの知識と理解を得られることです。 このブログが多くの質問の答えとなり、不安を和らげることができればと願っています。 <del> 別の情報をお探してあれば、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)を参照してください。 </del> <ins> 別の情報をお探しであれば、[dockershimの削除に関するFAQ](/ja/dockershim)を参照してください。 </ins>

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:
Some Kubernetes features exclusively use cgroup v2 for enhanced resource management and isolation. For example, the <del> [MemoryQoS](/blog/2021/11/26/qos-memory-resources/) feature improves memory QoS </del> <ins> [MemoryQoS](/docs/concepts/workloads/pods/pod-qos/#memory-qos-with-cgroup-v2) feature improves memory QoS </ins> and relies on cgroup v2 primitives.

Discussion:
chapter refers to the Memory QoS feature but pointing ; link should be updated to point to feature description in k8s official documentation.
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 reported in issue: /language en
I would like to work on this issue.
/assign
The issue is fixed .
Change:
<ins> <!-- Do not edit this file directly. Get the latest from https://github.com/cncf/foundation/blob/master/code-of-conduct/jp.md --> CNCF コミュニティ行動規範 v1.0 ------------------------------ ### コントリビューター行動規範 本プロジェクトのコントリビューターおよびメンテナーとして、オープンかつ快適なコミュニティを促進するために、私たちは、問題の報告、機能要求の投稿、ドキュメントの更新、プル要求またはパッチの送信、および他の活動を通して貢献するすべての人々を尊重することを誓います。 私たちは、経験レベル、性別、性の自認および表明、性的嗜好、障がい、個人的な外見、身体の大きさ、人種、民族、年齢、宗教、または国籍に関係なく、このプロジェクトへの参加を、全員にとってハラスメントがない経験にすることを約束します。 認められない参加者の行動の例: -	性的な言語またはイメージの使用 -	個人的な攻撃 -	煽りや侮辱/軽蔑的なコメント -	公開または非公開のハラスメント -	明示的な許可なく、物理的な住所や電子アドレスなど、他者の個人情報を公開すること -	他の倫理または職業倫理に反する行為。 プロジェクト メンテナーは、本行動規範に準拠していないコメント、コミット、コード、Wiki 編集、問題、他のコントリビューションを削除、編集、または却下する権利および責任を有しています。プロジェクト メンテナーは、本行動規範を採用することで、公正かつ一貫した方法で、これらの原則を本プロジェクトの管理におけるすべての要素に適用することに注力します。本行動規範を遵守または施行しないプロジェクト メンテナーは、永久的にプロジェクト チームから抹消される可能性があります。 個人がプロジェクトまたはコミュニティを代表するときには、本行動規範は、プロジェクト スペースおよび公共のスペースの両方に適用されます。 Kubernetesで虐待的、嫌がらせ、または許されない行動があった場合には、<conduct@kubernetes.io>から[Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct)（行動規範委員会）にご連絡ください。その他のプロジェクトにつきましては、CNCFプロジェクト管理者または仲介者<mishi@linux.com>にご連絡ください。 本行動規範は、コントリビューターの合意 (http://contributor-covenant.org) バージョン 1.2.0 http://contributor-covenant.org/version/1/2/0/ から適応されています。 ### CNCF イベント行動規範 CNCF イベントは、イベント ページにある Linux Foundation 行動規範 に準拠します。これは、前述のポリシーに対応し、インシデントへの対応に関する詳細を含めることを目的としています。 </ins>

Discussion:
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
Change:
kubectl config unset users.foo                       # delete user foo <del> # short alias to set/show context/namespace (only works for bash and bash-compatible shells, current context to be set before using kn to set namespace) </del> <ins> # short alias to set/show context/namespace (only works for bash and bash-compatible shells, current context to be set before using kn to set namespace) </ins> alias kx='f() { [ "$1" ] && kubectl config use-context $1 || kubectl config current-context ; } ; f' alias kn='f() { [ "$1" ] && kubectl config set-context --current --namespace $1 || kubectl config view --minify | grep namespace | cut -d" " -f6 ; } ; f' ```

Discussion:
Feedback a confusing point about kubectl command on page: <img width="1107" alt="image" src="https://user-""kubectl events " command seems just available in k8s-v1.26 release version, while below v1.26 not work yet. so a brief tip or comment on the page will be easy to understand. FYI.
Page: /language en /kind suggestion
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Page: /language en /kind suggestion 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
In my opinion, the cheat sheet is accurate for Kubernetes v1.26. However, if someone needs to refer to older documentation, they can access it by using the version selector option in the navigation bar. To improve clarity, the cheat sheet could integrate details from and provide explicit links within the content body to the other available versions. This approach would be more effective than simply relying on the version selector in the top navigation. Would folks consider this suggestion beneficial?
/retitle Improve clarity of kubectl Cheat Sheet with version information
I'd like to see a shortcode that renders as helper text to steer people to the right documentation, and a link to available versions. See for an example where I'd use this: we could replace that text with an even more helpful shortcode.
We could add a comment that this is accurate for this version of the docs. /priority backlog
I recommend the simple comment approach. We can still use version shortcodes, eg in the comment. /triage accepted
/assign
FYI
Change:
Kubernetesでは、アプリケーションの監視は1つの監視ソリューションに依存することはありません。 新しいクラスターでは、[リソースメトリクス](#resource-metrics-pipeline)または[フルメトリクス](#full-metrics-pipeline)パイプラインを使用してモニタリング統計を収集することができます。 <del> ## リソースメトリクスパイプライン </del> <ins> ## リソースメトリクスパイプライン {#resource-metrics-pipeline} </ins> リソースメトリックパイプラインは、[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/)コントローラーなどのクラスターコンポーネントや、`kubectl top`ユーティリティに関連する限定的なメトリックセットを提供します。

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. -- page has some problems. -page link isn't working. resource metrics pipeline full metrics pipeline the Japanese page exists, some links jump to the English page. Pod Service Why is this needed it is inconvenient for the user. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted
Change:
# CRI-O 설치 sudo apt-get install cri-o-1.17 ``` <del> {{< /tab >}} </del> <ins> {{% /tab %}} </ins> <del> {{< tab name="CentOS/RHEL 7.4+" >}} </del> <ins> {{% tab name="CentOS/RHEL 7.4+" %}} </ins> ```shell # 선행 조건 설치

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: Broken layout for tabs on "Container runtimes" page as below. ! Proposed Solution: TBD Page to Update: /language ko <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/retitle Broken layout for tabs on "Container runtimes" page in Korean
This problem is due to incorrect tab code. We should fix this like the below: (Line 71, 125, 126, 180) to
/good-first-issue
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 : /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
Hey folks, I'm happy to help you with this /assign
Change:
1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 addresses for the service. The control plane updates the `.spec` for the Service to record the IP <del> address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from `.spec.ClusterIPs`. </del> <ins> address assignments. The field `.spec.clusterIPs` is the primary field, and contains both assigned IP addresses; `.spec.clusterIP` is a secondary field with its value calculated from `.spec.clusterIPs`. </ins> <del> * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the </del> <ins> * For the `.spec.clusterIP` field, the control plane records the IP address that is from the </ins> same address family as the first service cluster IP range. <del> * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list </del> <ins> * On a single-stack cluster, the `.spec.clusterIPs` and `.spec.clusterIP` fields both only list </ins> one address. * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` behaves the same as `PreferDualStack`.

Discussion:
page is plenty of wrong references to the non defined ` instead.
/triage accepted
/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 : /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
/kind bug
/assign
Thanks for solving this so so quick (you are the best ;-)
Change:
As you can see, configuration for a TCP check is quite similar to an HTTP check. This example uses both readiness and liveness probes. The kubelet will send the <del> first readiness probe 5 seconds after the container starts. This will attempt to </del> <ins> first readiness probe 15 seconds after the container starts. This will attempt to </ins> connect to the `goproxy` container on port 8080. If the probe succeeds, the Pod will be marked as ready. The kubelet will continue to run this check every 10 seconds.

Discussion:
This is a Bug Report Problem: The intial definiton given in doesn't describe that if the first probe time will be = . For example: The pod will be marked as after 60s, (tested in k8s v1.22.10). Moreover, the given if i read this code correctly, then the check is done for and the check for is done after assuming that value of Proposed Solution: Allign code and the documentation. Page to Update:
/sig docs /language en
/assign
I did tested this on the k8s 1.27 and it's still same.
I believe this is a corner case. Why do you set initialDelaySeconds to be shorter than perdioSeconds in the first place? I'm not objecting the clarification, BTW. What I am wondering is if there is a real case people will do this.
Okay. I get it now. The example manifest has a problem to fix. Thanks for raising up this.
/triage accepted
thanks :)