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: The mentions adding Windows nodes to your cluster as a production consideration. In fact, you might want to do this whether your cluster is running in production or not. Proposed Solution: Remove the paragraph that starts “Add Windows nodes to the cluster” from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: We missed that removal from PR Also relevant (a bit) to issue /language en /kind bug /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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The mentions adding Windows nodes to your cluster as a production consideration. In fact, you might want to do this whether your cluster is running in production or not. Remove the paragraph that starts “Add Windows nodes to the cluster” from <!--Kubernetes Version:--We missed that removal from PR Also relevant (a bit) to issue /kind bug /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
/triage accepted
/assign

Discussion:
add nodes by setting up your own machines and either adding them manually or having them register themselves to the cluster’s apiserver. See the [Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. <del> - *Add Windows nodes to the cluster*: Kubernetes offers support for Windows worker nodes, allowing you to run workloads implemented in Windows containers. See [Windows in Kubernetes](/docs/setup/production-environment/windows/) for details. </del> - *Scale nodes*: Have a plan for expanding the capacity your cluster will eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) to help determine how many nodes you need, based on the number of pods and
Change:
! The label with the key not exist in the example for node affinity:
/kind bug /language en /triage accepted Thanks for reporting this. I would fix this discrepancy by copying the example manifest to make a new example, that does use the key key. The Git history might show a previous version that already did, which would make it easier to write the copy. The reason I'd make that copy is because I suspect that more than one page relies on the same example (and that's why an unhelpful change has slipped through).
/assign

Discussion:
requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: topology.kubernetes.io/zone </del> <ins> - key: kubernetes.io/os </ins> operator: In values: <del> - antarctica-east1 - antarctica-west1 </del> <ins> - linux </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:

requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/os </del> <ins> - key: topology.kubernetes.io/zone </ins> operator: In values: <del> - linux </del> <ins> - antarctica-east1 - antarctica-west1 </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:
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's some text on some of the pages about CronJob ; for example, When Kubernetes v1.25 is released, we can (and think should) remove that text, because none of the versions before 1.21 would be in support. Proposed Solution: Remove that paragraph. :informationsource: make the update on the dev-1.25 branch Page to Update: Kubernetes Version: v1.25 (upcoming)_ Additional Information: /sig apps /language en /kind cleanup /milestone 1.25
/assign
/triage accepted
/assign
/unassign
Thank you

Discussion:
<!-- overview --> <del> CronJobs was promoted to general availability in Kubernetes v1.21. If you are using an older version of Kubernetes, please refer to the documentation for the version of Kubernetes that you are using, so that you see accurate information. Older Kubernetes versions do not support the `batch/v1` CronJob API. </del> You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} on a time-based schedule. These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system.
Change:
This is a Bug Report cannot sync files under correctly. This problem should exist with $LOCALIZED more than 2 characters. When happened when zh -zh-cn see <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Proposed Solution:** needs to be updated to <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/cc /language zh
/triage accepted
I found this problem when reviewing this PR , the commit time of the version is later than the version, but did not correctly find the difference between the 2 versions.
nice catch!
When the script was developed, I was only focusing on markdown files.

Discussion:
if [ -d "$1" ] ; then SYNCED=1 for f in `find $1 -name "*.md"` ; do <del> EN_VERSION=`echo $f | sed "s/content/..//content/en//g"` </del> <ins> EN_VERSION=`echo $f | sed "s/content/.{2,5}//content/en//g"` </ins> if [ ! -e $EN_VERSION ]; then echo -e "**removed**t$EN_VERSION" SYNCED=0

LOCALIZED="$1" # Try get the English version <del> EN_VERSION=`echo $LOCALIZED | sed "s/content/..//content/en//g"` </del> <ins> EN_VERSION=`echo $LOCALIZED | sed "s/content/.{2,5}//content/en//g"` </ins> if [ ! -e $EN_VERSION ]; then echo "$EN_VERSION has been removed." exit 3
Change:
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. --This extra "the" should be removed for better readability. ! Why is this needed For the improvement of the docs this extra "the" should be removed. file link :-
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
: Please check the comments against PR . Thank you for suggesting this amendment, however, we'd request that when you suggest such trivial edits you check the entire document for any other mistakes that might need rectification.

Discussion:
### Language specific Zoom meetings If the localization project needs a separate meeting time, contact a SIG Docs Co-Chair or Tech <del> Lead to create a new reoccurring Zoom meeting and calendar invite. This is only needed when the </del> <ins> Lead to create a new reoccurring Zoom meeting and calendar invite. This is only needed when </ins> the team is large enough to sustain and require a separate meeting. Per CNCF policy, the localization teams must upload their meetings to the SIG Docs YouTube
Change:
Only minor confusion, after the first example Pod spec, where "In this example, the following rules apply:" the bullet points that follow are misleading where first bullet refers to the example below, the second to the example above.
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

Discussion:
requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: topology.kubernetes.io/zone </del> <ins> - key: kubernetes.io/os </ins> operator: In values: <del> - antarctica-east1 - antarctica-west1 </del> <ins> - linux </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:

requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/os </del> <ins> - key: topology.kubernetes.io/zone </ins> operator: In values: <del> - linux </del> <ins> - antarctica-east1 - antarctica-west1 </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:
Change:
This page is missing the commands to install containerd. At the anchor , there is the following text: "Use the following commands to install Containerd on your system:" Yet there is nothing below this instructing how to perform the install. I believe it should have something along the lines of: But the actual instructions for installing containerd appear to be missing. Below this we find the following text indicating that a restart of the newly installed containerd service should be performed, but the instructions to perform the actual install are missing. "If you apply this change, make sure to restart containerd:" `sudo systemctl restart containerd'
Page: /language en
/assign
Hi , There's already a line mentioned to go through this link () and then come back to this step.
We should remove the text "Use the following commands to install Containerd on your system:” as these are obsolete. Instead, we expect the containerd documentation to cover that detail.
We could also revise the text to make it clear that following those third-party docs is a required step towards having a working containerd.
/assign
/triage accepted
Perfect , I'll commit the changes as required !
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
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

Discussion:
This section outlines the necessary steps to use containerd as CRI runtime. <del> Use the following commands to install Containerd on your system: Follow the instructions for [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). Return to this step once you've created a valid configuration file, `config.toml`. </del> <ins> To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).Return to this step once you've created a valid `config.toml` configuration file. </ins> {{< tabs name="Finding your config.toml file" >}} {{% tab name="Linux" %}}
Change:
When enabling dynamic provisioning as default behaviour: It might be helpful to reference the following as a hyper link for clarity
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind feature /language en It sounds as if we could add a hyperlink from to and that would solve it for you Have I got that right?
Hi Tim, I would agree this would be awesome for users. Kind regards Naresh Maharaj
would you be willing to update (edit) the issue description, with in mind, so that it's clear what change you are asking for?
/sig storage
/assign

Discussion:
is enabled on the API server. An administrator can mark a specific `StorageClass` as default by adding the <del> `storageclass.kubernetes.io/is-default-class` annotation to it. </del> <ins> `storageclass.kubernetes.io/is-default-class` [annotation](/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) to it. </ins> When a default `StorageClass` exists in a cluster and a user creates a `PersistentVolumeClaim` with `storageClassName` unspecified, the `DefaultStorageClass` admission controller automatically adds the
Change:
This is a Bug Report <!--Required Information--Problem: The Feature state of is mentioned as under task, Which is not correct. In k8s v1.24.0 is graduated to . See the of k8s v1.24.0 and Also mention under the . Proposed Solution: Change the Feature State of from Kubernetes v1.20 [alpha] to Kubernetes v1.24 [beta]. Page to Update:
/assign
fixed it here:
As this is a bug report issue, I'm going to change the title to summarize what isn't right. /retitle Incorrect feature state data for kubelet credential provider Also: /language en /triage accepted /sig node
thanks

Discussion:
content_type: task --- <del> {{< feature-state for_k8s_version="v1.20" state="alpha" >}} </del> <ins> {{< feature-state for_k8s_version="v1.24" state="beta" >}} </ins> <!-- overview -->
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: states: However, there is no such option in current Kubernetes. At least, I couldn't see it. As far as I can tell, the mechanisms that would work are: to perform the bootstrap when authenticated as a member of . Because this is an API server restriction, you can't configure an extra authorizer during initial bootstrap (such as a webhook authorizer). However, once any principal is bound to a ClusterRole that is allowed to escalate, it's all good and further bootstrapping can take place as that cluster role. Proposed Solution: Remove that item from the page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /sig auth
/assign
/triage accepted
I see that you haven't worked on this for long, so I stepped up and did this. Thank you for your interest /assign
/unassign

Discussion:
To bootstrap initial roles and role bindings: * Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. <del> * If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. </del> ## Command-line utilities
Change:
In the section, it could be really helpful to add a callout note that the secret MUST be of . I spent hours trying to debug image pull issues because my image pull secret was of the default secret type (Opaque) instead of .
/retitle Call out that image pull Secrets must be of appropriate type /language en /kind feature
/triage accepted with the proviso that the PR will need tech review: I haven't looked at the code to check the list of Secret types that are acceptable.
/assign
Hi These are the types of secrets that are supported And we use and as a type for . I hope this will be helpful for the PR.

Discussion:
{{< /note >}} Kubernetes supports specifying container image registry keys on a Pod. <ins> `imagePullSecrets` must all be in the same namespace as the Pod. The referenced Secrets must be of type `kubernetes.io/dockercfg` or `kubernetes.io/dockerconfigjson`. </ins> #### Creating a Secret with a Docker config

#### Referring to an imagePullSecrets on a Pod Now, you can create pods which reference that secret by adding an `imagePullSecrets` <del> section to a Pod definition. </del> <ins> section to a Pod definition. Each item in the `imagePullSecrets` array can only reference a Secret in the same namespace. </ins> For example:
Change:
This is a Bug Report Problem: The following page writes: As discussed in issue , the use of "privileged" in the phrase "create a privileged Pod" is not standard usage and causes confusion because the pod is not created with the privileged flag (as ). This means that commands such as fail with and reading some process information may fail with . Proposed Solution: As far as what the actual clarification should be instead of the word "privileged", I'm not sure. I think a subject matter expert should opine on that. My guess is it should be something along the lines of: Page to Update: FYI
/assign
/sig cli /language en /triage accepted /remove-kind bug /priority backlog
/unassign PR is an attempt to resolve this issue, but the PR has been closed and this issue is not resolved yet. Please take a look discussions and suggestions in the PR before self-assign. :)
/good-first-issue /assign
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 /assign 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
The PR for this issue has already been raised earlier.

Discussion:
## Debugging via a shell on the node {#node-shell-session} If none of these approaches work, you can find the Node on which the Pod is <del> running and create a privileged Pod running in the host namespaces. To create an interactive shell on a node using `kubectl debug`, run: </del> <ins> running and create a Pod running on the Node. To create an interactive shell on a Node using `kubectl debug`, run: </ins> ```shell kubectl debug node/mynode -it --image=ubuntu

* `kubectl debug` automatically generates the name of the new Pod based on the name of the Node. <del> * The container runs in the host IPC, Network, and PID namespaces. </del> * The root filesystem of the Node will be mounted at `/host`. <ins> * The container runs in the host IPC, Network, and PID namespaces, although the pod isn't privileged, so reading some process information may fail, and `chroot /host` will fail. * If you need a privileged pod, create it manually. </ins> Don't forget to clean up the debugging Pod when you're finished with it:
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: is blank for the main page content. Proposed Solution: Delete (fall back to English) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language fr
/triage accepted
It have to be deleted and what do you mean by fall back to english? Could you please elaborate?
I guess falling back means the menu link of the French website should lead to (i.e. its English version) instead of since there is no content in the French version. However, I don't understand where this URL () originates from. The partial seems to be incorrect as it always links to the page (despite the website's language currently in use), doesn't it? E.g., there is the content for the locale, but the navigation menu on still leads to the page, not .
/assign
There are 2 issues here: I took a look and indeed, introduced the issue since it a new page under the subfolder. Moreover, is correct, you can get to these translation by going on the page and clicking the language dropdown, and selecting Français but the always redirect to the English version.
/area localization
Both issues were resolved and merged!

Discussion:
<ins> --- linktitle: Historique des versions title: Versions type: docs --- <!-- overview --> Le projet Kubernetes maintient des branches de versions pour les trois versions mineures les plus récentes ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 et plus récent reçoivent [environ 1 an de support de correctifs](/releases/patch-releases/#support-period). Kubernetes 1.18 et plus ancien ont reçu environ 9 mois de support de correctifs. Les versions de Kubernetes sont exprimées sous la forme **x.y.z**, où **x** est la version majeure, **y** est la version mineure et **z** est la version du correctif, selon la terminologie de [Gestion sémantique de version](https://semver.org/lang/fr/). Plus d'informations dans le document sur la [politique en matière de version](/releases/version-skew-policy/). <!-- body --> ## Historique des versions {{< release-data >}} ## Publication à venir Consultez la [planification](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) pour la prochaine version **{{< skew nextMinorVersion >}}** de Kubernetes ! ## Ressources utiles </ins>

[input_placeholder_email_address] other = "adresse email" <ins> [latest_release] other = "Dernière version:" [end_of_life] other = "Fin du support:" [previous_patches] other = "Correctifs publiés:" [release_date_before] other = "(publiée: " </ins>
Change:
says the minimal supported CNI interface version is 0.4.0 and specification-version 1.0.0 is recommended. Neverthesless the same webpage contains two examples with .
/assign
/language en /triage accepted

Discussion:
```json { "name": "k8s-pod-network", <del> "cniVersion": "0.3.0", </del> <ins> "cniVersion": "0.4.0", </ins> "plugins": [ { "type": "calico",