jiebi/CodeConvo huggingface dataset:
Code change:
{{% capture overview %}} <del> {{< feature-state state="beta" >}} </del> <ins> {{< feature-state state="beta" for_k8s_version="v1.18" >}} </ins> An increasing number of systems leverage a combination of CPUs and hardware accelerators to support latency-critical execution and high-throughput parallel computation. These include workloads in fields such as telecommunications, scientific computing, machine learning, financial services and data analytics. Such hybrid systems comprise a high performance environment.

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: has a feature-state shortcode: this shortcode doesn't track when the feature went beta. Proposed Solution: Change that line to: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /help /language en /priority backlog /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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: has a feature-state shortcode: Change that line to: <!--Kubernetes Version:--/help /language en /priority backlog /good-first-issue </details
/assign
Code change:
## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs.md" >}} </ins>

Related discussion:
text: This is a clean up issue <!-- 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 changed Look at Make sure that all the version constraints in the page make sense and related to the list of Kubernetes versions that are for documentation. There is a shortcode in the page that expects a value in the page front matter. ~Replace that shortcode with English text that explains in words what versions the reader should have. (to save you having to check: you can only configure a startup probe if you have Kubernetes v1.16 or later and if you have enabled the )~ Remove that shortcode. Why is this needed doesn't clearly tell readers about the version of Kubernetes they need to be running and the feature gate(s) they might need to enable. Comments /help /kind cleanup If you're looking at this, you might also want to tackle issue
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 : This is a clean up issue <!-- See for guidance on writing an actionable issue description. --Look at (to save you having to check: you can only configure a startup probe if you have Kubernetes v1.16 or later and if you have enabled the ) doesn't clearly tell readers about the version of Kubernetes they need to be running and the feature gate(s) they might need to enable. /help /kind cleanup 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-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/language en /lifecycle frozen
/assign I'll probably be back with questions - where's better to post/ask, here on the issue, or in Slack?
Should I just add the info for Startup probes?
Code change:
## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs.md" >}} </ins>

Related discussion:
text: I see that they came last with the feature gate in 1.16 onwards, checking now re: Liveness and Readiness but I guess they're earlier than the supported doc versions. Still would be nice to mention though - as a reader with maybe a bit less context I would get confused if the page title mentions 3 kinds of probes and the docs only talk about version requirements for one type of probe.
Also at this point for the feature flag since it went beta in 1.18 and GA in 1.20 the text would be something like: Kubernetes v1.16 and v1.17 require the to be set. Startup probes are enabled by default in Kubernetes v1.18 onwards.
IMO it's OK to focus on documenting for v1.21, the current documentation version. If we want to backport the equivalent change to the older documentation, that's an option too. For example, if you want to revise https://v1- to explain the feature gate, that's OK (but also not a priority).
how do I go about editing the old version of the docs? Or is there a how-to/readme somewhere? I've submitted a PR for the current version/file with the text I suggested: Do you know btw when Liveness and Readiness probes went alpha/beta/GA? I found Liveness probes introduced but haven't found Readiness probes yet. Anyways given that it's all the way in 2014 I think it's safe to omit specific versions. I updated the text to read: lmk what you think
Since I opened this issue, several Kubernetes releases have come out and I didn't update the issue text to clarify it. I have now.
If all PRs were this simple Actually it turns out some of them really are :)
Code change:
spec: containers: - name: php-redis <del> image: gcr.io/google_samples/gb-frontend:v5 </del> <ins> image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5 </ins> env: - name: GET_HOSTS_FROM value: "dns"

Related discussion:
text: The yaml file in "Creating the Guestbook Frontend Deployment" uses an image no more available ( ) I solved the issue by using Here is the working version I used!
Hey Can you share us a pic of the solved issue here?
/kind bug
/triage accepted
/assign
Code change:
spec: containers: - name: php-redis <del> image: gcr.io/google_samples/gb-frontend:v5 </del> <ins> image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5 </ins> env: - name: GET_HOSTS_FROM value: "dns"

Related discussion:
text: The image file download for the frontend- is currently failing. I fixed by changing it to: image: us-
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
This looks similar to issue(s) and I think it is a duplicate. /triage duplicate
Fixes are welcome; please visit to discuss and track that work.
Closing this issue, resolved by PR
/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:
--> ## 资源要求 <del> 使用有限的资源运行 etcd 只适合测试目的。为了在生产中部署，需要先进的硬件配置。在生产中部署 etcd 之前，请查看[所需资源参考文档](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#example-hardware-configurations)。 </del> <ins> 使用有限的资源运行 etcd 只适合测试目的。为了在生产中部署，需要先进的硬件配置。 在生产中部署 etcd 之前，请查看 [所需资源参考文档](https://etcd.io/docs/current/op-guide/hardware/#example-hardware-configurations)。 </ins> ## 启动 etcd 集群

Related discussion:
text: " etcd "client.cert " etcd etcd " " etcd client.key etcd "
~ GitHub is not the right place for support requests.~ ~If you're looking for help, oyu could ask on .~ ~You can also post your question on the or the forum. There are other support venues with contributions from the wider community of Kubernetes users.~
/triage accepted /kind bug
/remove-kind support
Thanks
/language zh
/priority backlog
Code change:
<ins> --- title: "Kubernetesオブジェクトの管理" description: Kubernetes APIと対話するための宣言型および命令型のパラダイム。 weight: 25 --- </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
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:
[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). User defined environment variables from the Pod definition are also available to the Container, <del> as are any environment variables specified statically in the Docker image. </del> <ins> as are any environment variables specified statically in the container image. </ins> ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services. <del> Those environment variables match the syntax of Docker links. </del> For a service named *foo* that maps to a Container named *bar*, the following variables are defined:

Related discussion:
text: Ref: The page is centered around Docker examples and needs a rewrite in light of the Dockershim removal. /triage accepted /milestone 1.24
/sig node
Hi, I would like to work on this but I may need a little help. When we say "rewrite in light of the Dockershim removal", does it just means removing the Docker references on the page ( i.e removing "" on this page) or something more is expected.
Thanks for taking this on. In my opinion, there are two issues to deal with here. The first is easy. Change "Docker image" to "container image". I believe the second instance refers to a legacy Docker feature called . I think it is safe to just remove that sentence.
Thankyou :) I'll make a PR by tomorrow /assign
Code change:
<p>Create a TLS secret from the given public/private key pair.</p> <p> The public/private key pair must exist beforehand. The public key certificate must be .PEM encoded and match the given private key.</p> <h3 id="usage">Usage</h3> <del> <p><code>$ kubectl create tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]</code></p> </del> <ins> <p><code>$ kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]</code></p> </ins> <h3 id="flags">Flags</h3> <table> <thead>

Related discussion:
text: Hello team. Recently I noticed that this page: shows wrong command. Instead of it should be I believe the fix should go into this file Please review. Thank you
/assign
- -- -- -- -- -- -- -Also see this:
should this issue and its corresponding PR be closed?
closed his prior PR, and opened . IMO it would be good to keep this issue open until the error in K8s Docs has been resolved. /kind bug
Okay
/triage accepted
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]:
Should the PR be opened in Kuberenetes/website?
/remove-lifecycle stale
Code change:
### CRIの設定 {#cri-configuration} <del> CRIランタイムのセットアップに関するさらなる詳細は、[CRIのインストール](/docs/setup/cri/)を参照してください。 </del> <ins> CRIランタイムのセットアップに関するさらなる詳細は、[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)を参照してください。 </ins> #### {{< glossary_tooltip term_id="containerd" >}}

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. --Update Japanese translation Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --ref. /language ja
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 want to work on this. Have you already started working on it? It seems that some pages linked from here are not translated yet: dockershim-removal template For now, I'm going to start working on dockershim related contents. Feel free to notify me if this conflicts with your work.
I'll assign myself since you haven't assigned youself to this issue. Please tell me if this conflicts with you work. /assign
Code change:
### Create a CertificateSigningRequest {#create-certificatessigningrequest} <del> Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest. </del> <ins> Create a [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/) and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest. </ins> ```shell cat <<EOF | kubectl apply -f -

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 the document , it would be helpful to link to the . Why is this needed I was studying for the CKA exam, and was practicing only using the pages to search for info about CertificateSigningRequests. The doc came up readily, but the was not so easily discoverable via a search using only the search interface. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/triage accepted
Code change:
### Access Modes <del> A `PersistentVolume` can be mounted on a host in any way supported by the resource provider.  Providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only.  Each PV gets its own set of access modes describing that specific PV's capabilities. </del> <ins> A `PersistentVolume` can be mounted on a host in any way supported by the resource provider.  As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume.  For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only.  Each PV gets its own set of access modes describing that specific PV's capabilities. </ins> The access modes are:

Related discussion:
text: This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: The command to create the sock-shop application error out (it's also not necessary to create the namespace beforehand as that is already define in ): Proposed Solution: Change the command to: Page to Update: Kubernetes Version: 1.6.1
I think this is an issue that needs to be fixed in socks shop.
This merged PR should resolve the issue
Code change:
spec: containers: - name: follower <del> image: gcr.io/google_samples/gb-redis-follower:v2 </del> <ins> image: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2 </ins> resources: requests: cpu: 100m

Related discussion:
text: The yaml file in "Creating the Guestbook Frontend Deployment" uses an image no more available ( ) I solved the issue by using Here is the working version I used!
Hey Can you share us a pic of the solved issue here?
/kind bug
/triage accepted
/assign
Code change:
spec: containers: - name: follower <del> image: gcr.io/google_samples/gb-redis-follower:v2 </del> <ins> image: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2 </ins> resources: requests: cpu: 100m

Related discussion:
text: The image file download for the frontend- is currently failing. I fixed by changing it to: image: us-
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
This looks similar to issue(s) and I think it is a duplicate. /triage duplicate
Fixes are welcome; please visit to discuss and track that work.
Closing this issue, resolved by PR
/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:
localization's two-letter language code. For example, the two-letter code for Korean is `ko`. <ins> Some languages use a lowercase version of the country code as defined by the ISO-3166 along with their language codes. For example, the Brazilian Portuguese language code is `pt-br`. </ins> ### Fork and clone the repo First, [create your own

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. --Currently, the documentation for starting a new localization instructs only to use the language code. However, some of the languages for which the website is currently localized also have the country code, due to Docsy specificities and because the language is written differently in the places where it is spoken. Document a general guideline of when and how a language should also contain the country code attached to it when localizing Kubernetes documentation, so new locales follow the country code standard when it makes sense to do so. Why is this needed To make sure that previous decisions made by localization teams are documented in in our page. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --This is a follow-up issue to discussion on . /assign /cc
/triage accepted
Code change:
[deprecation_file_warning] other = "Przestarzały" <ins> [dockershim_message] other = """Dockershim został usunięty z projektu Kubernetes w wydaniu 1.24. Po dalsze informacje zajrzyj do <a href="/dockershim">Dockershim Removal FAQ</a>.""" </ins> [docs_label_browse] other = "Przeglądaj dokumentację"

Related discussion:
text: What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language pl
/sig docs
/triage accepted
Code change:
是集群范围资源用量数据的聚合器。 默认情况下，在由 `kube-up.sh` 脚本创建的集群中会以 Deployment 的形式被部署。 如果你使用其他 Kubernetes 安装方法，则可以使用提供的 <del> [部署组件 components.yaml](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy) </del> <ins> [部署组件 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) </ins> 来部署。 <!--

Related discussion:
text: deployment does not exist
/retitle [zh] Issue with
/triage accepted /language zh
In English page, the links goes to
/assign
The reason is that the Chinese version link is not synchronized with the English version. However, when I synchronized the pipeline page, I found that there was a problem with other content that needed to be synchronized , and I needed to wait for this issue to be solved before I could synchronize.
Code change:
* clean composition of Kubelet-level functionality with cluster-level functionality &mdash; Kubelet is effectively the "pod controller" * high-availability applications, which will expect pods to be replaced in advance of their termination and certainly in advance of deletion, such as in the case of planned evictions, image prefetching, or live pod migration [#3949](http://issue.k8s.io/3949) <del> There is new first-class support for stateful pods with the [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) controller (currently in beta). The feature was alpha in 1.4 and was called PetSet. For prior versions of Kubernetes, best practice for having stateful pods is to create a replication controller with `replicas` equal to `1` and a corresponding service, see [this MySQL deployment example](/docs/tutorials/stateful-application/run-stateful-application/). </del> ## Termination of Pods Because pods represent running processes on nodes in the cluster, it is important to allow those processes to gracefully terminate when they are no longer needed (vs being violently killed with a KILL signal and having no chance to clean up). Users should be able to request deletion and know when processes terminate, but also be able to ensure that deletes eventually complete. When a user requests deletion of a pod the system records the intended grace period before the pod is allowed to be forcefully killed, and a TERM signal is sent to the main process in each container. Once the grace period has expired the KILL signal is sent to those processes and the pod is then deleted from the API server. If the Kubelet or the container manager is restarted while waiting for processes to terminate, the termination will be retried with the full grace period.

Related discussion:
text: This is a... [ ] Feature Request [x] Bug Report Problem: There is a link missing that was supposed to be in section Differences between alpha PetSets and beta StatefulSets under it in the second point StatefulSet guards against split brain which ends with following text TODO: Link to doc about fencing. Change it and add the link that is required. Proposed Solution: Add link which is missing Page to Update:
PetSet has long been replaced by StatefuSet and StatefulSet has been GA'ed in 1.9. So we are going to remove this page to avoid further confusion.