jiebi/CodeConvo huggingface dataset:
Code change:
This is a Bug Report It's not a bug, just an outdated doc thing. Problem: The MutatingWebhookConfiguration and ValidatingWebhookConfiguration APIs have been promoted to in . But the docs still show that they are in beta state at and . Proposed Solution: the description from the two plug-ins. the descriptions of the two plug-ins if they need an update too. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
I'm investigating this issue, hope I can send a PR for this after someone triaged/confirmed it. /assign
/triage accepted

Related discussion:
text: different when read back. * Setting originally unset fields is less likely to cause problems than overwriting fields set in the original request. Avoid doing the latter. <del> * This is a beta feature. Future versions of Kubernetes may restrict the types of mutations these webhooks can make. </del> * Future changes to control loops for built-in resources or third-party resources may break webhooks that work well today. Even when the webhook installation API is finalized, not all possible webhook behaviors will be guaranteed to be supported
Code change:
This is a Bug Report It's not a bug, just an outdated doc thing. Problem: The MutatingWebhookConfiguration and ValidatingWebhookConfiguration APIs have been promoted to in . But the docs still show that they are in beta state at and . Proposed Solution: the description from the two plug-ins. the descriptions of the two plug-ins if they need an update too. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
I'm investigating this issue, hope I can send a PR for this after someone triaged/confirmed it. /assign
/triage accepted

Related discussion:
text: ### ValidatingAdmissionWebhook {#validatingadmissionwebhook} <del> {{< feature-state for_k8s_version="v1.13" state="beta" >}} </del> This admission controller calls any validating webhooks which match the request. Matching webhooks are called in parallel; if any of them rejects the request, the request fails. This admission controller only runs in the validation phase; the webhooks it calls may not
Code change:
This is a Bug Report It's not a bug, just an outdated doc thing. Problem: The MutatingWebhookConfiguration and ValidatingWebhookConfiguration APIs have been promoted to in . But the docs still show that they are in beta state at and . Proposed Solution: the description from the two plug-ins. the descriptions of the two plug-ins if they need an update too. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
I'm investigating this issue, hope I can send a PR for this after someone triaged/confirmed it. /assign
/triage accepted

Related discussion:
text: webhooks or other validating admission controllers will permit the request to finish. If you disable the ValidatingAdmissionWebhook, you must also disable the <del> `ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1beta1` </del> <ins> `ValidatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1` </ins> group/version via the `--runtime-config` flag (both are on by default in versions 1.9 and later).
Code change:
In the table of of there are two descriptions missing of two tolerations kyes, one is another one is , their descriptions are missing.
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

Related discussion:
text: | ---------------------------------------- | ---------- | ------- | ----------- | | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | DaemonSet pods will not be evicted when there are node problems such as a network partition. | <del> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | | </del> <ins> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | DaemonSet pods tolerate disk-pressure attributes by default scheduler. | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | DaemonSet pods tolerate memory-pressure attributes by default scheduler. | </ins> | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet pods tolerate unschedulable attributes by default scheduler. | | `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+   | DaemonSet pods, who uses host network, tolerate network-unavailable attributes by default scheduler. |
Code 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 For the pages: the part before is sometimes a plural and sometimes not. We should make this consistent. Why is this needed When we use language inconsistently, that language becomes harder for (some) localization teams to translate well. Additionally, readers might see the different pluralization and wonder (perhaps even believe) that it is significant, given the authority attached to the website where it appears. Comments /language en /kind cleanup
/triage accepted
you might want to know about this issue - I am sure you would have some tips for a person picking it up
This change needs to happen in the generator, ? The idea is to make the resource type or category singular?
That's the approach I'd take.

Related discussion:
text: Suppose that we made a typo while updating the Deployment, by putting the image name as `nginx:1.91` instead of `nginx:1.9.1`: <ins> {% include code.html language="yaml" file="bad-nginx-deployment.yaml" ghlink="/docs/user-guide/bad-nginx-deployment.yaml" %} </ins> ```shell $ kubectl apply -f docs/user-guide/bad-nginx-deployment.yaml deployment "nginx-deployment" configured
Code 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: "FrameworkHandle" link is broken. Proposed Solution: The link should be ( ) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /triage accepted
/assign

Related discussion:
text: {{< note >}} While any plugin can access the list of "waiting" Pods and approve them <del> (see [`FrameworkHandle`](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20180409-scheduling-framework.md#frameworkhandle)), we expect only the permit </del> <ins> (see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit </ins> plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod is approved, it is sent to the [PreBind](#pre-bind) phase. {{< /note >}}
Code change:
Link broken or pointing to a wrong link. Under section: Programmatic access to the API. The link provided in the below line seems to be broken to wrong.
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 think this report is about the page can you paste in the text (or HTML source) of the broken hyperlink /triage needs-information

Related discussion:
text: } ``` <del> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](#accessing-the-api-from-within-a-pod). </del> <ins> If the application is deployed as a Pod in the cluster, see [Accessing the API from within a Pod](/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod). </ins> #### Python client
Code change:
По ссылке получаю страницу "404"
/language ru /kind bug
Страница на текущий момент не вся актуальна. Используйте английскую версию.
/triage accepted

Related discussion:
text: * Пробуете или начинаете работу с Kubernetes * Локально разрабатываете и тестируете кластер <del> Выбрать [решение для запуска на локальной машине](/docs/setup/pick-right-solution/#local-machine-solutions). </del> <ins> Выбрать [решение для запуска на локальной машине](/docs/setup/learning-environment/). </ins> ## Управляемые решения
Code change:
includes the deadlink:
/kind bug /triage accepted /language en
/sig cluster-lifecycle node i've LGTM on the pending PR.
/retitle container-runtime: migration guide points to a 404
this PR did not fix the problem: because it lacks a leading i will send a new one.
new fix is here:

Related discussion:
text: ### Migrating to the `systemd` driver in kubeadm managed clusters <del> Follow this [Migration guide](docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </del> <ins> Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver) </ins> if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters. ## Container runtimes
Code change:
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

Related discussion:
text: <ins> --- title: "Kubernetesオブジェクトの管理" description: Kubernetes APIと対話するための宣言型および命令型のパラダイム。 weight: 25 --- </ins>
Code 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 example at shows in the being used without . Because (by default?) sets up the scheduler to run inside a pod, it is necessary to use to mount the config file into the pod. Using the example as given will cause the scheduler to fail to start, even if the referenced config file exists on the host. It is also not mentioned here that providing a config file (now?) causes the scheduler to ignore several of the flags (like and ) that kubeadm sets the scheduler up with, so any config file passed needs to duplicate those settings if the scheduler is to work as kubeadm intends. In particular, without setting a , the scheduler will not come up. This documentation is especially important because doesn't necessarily work before the scheduler can schedule enough Kubernetes components to start up TLS, so it can be nearly impossible to debug what is wrong with a non-working scheduler pod without a lot of documentation. Proposed Solution: A working example that lets the scheduler come up with a nontrivial configuration change seems to be: Scheduler config file on host in e.g. : Config file for to point to and mount it: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.19.3 <!--Additional Information:--
no other ways are supported, by kubeadm. i can see how the kubeadm example may be bogus in that regard. if scheduler config overrides flags that is an artifact of the kube-scheduler. normally flags should override config, or the mixture should just error out. if some kube-scheduler specifics are not documented they should go here: or here: kubeadm just allows you to configure it and i don't think we should special case the component a lot here: having the following minimal example makes sense to me: ^ this sentence can also be extended to link to /sig cluster-lifecycle scheduling /triage accepted PRs are welcome.
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /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
perhaps pages like: should start linking to the respective component config pages too:
/assign

Related discussion:
text: kubernetesVersion: v1.16.0 scheduler: extraArgs: <del> bind-address: 0.0.0.0 config: /home/johndoe/schedconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml </del> <ins> config: /etc/kubernetes/scheduler-config.yaml extraVolumes: - name: schedulerconfig hostPath: /home/johndoe/schedconfig.yaml mountPath: /etc/kubernetes/scheduler-config.yaml readOnly: true pathType: "File" </ins> ```
Code change:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.

Related discussion:
text: --- title: Service Accounts description: > <del> Learn about the Kubernetes ServiceAccount object. </del> <ins> Learn about ServiceAccount objects in Kubernetes. </ins> content_type: concept weight: 10 ---
Code change:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.

Related discussion:
text: the configurations portable. Service accounts are different from user accounts, which are authenticated <del> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </del> <ins> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </ins> data. You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.
Code change:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.

Related discussion:
text: object named `default` for every namespace in your cluster. The `default` service accounts in each namespace get no permissions by default other than the [default API discovery permissions](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) <del> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{<glossary_tooltip text="control plane" term_id="control-plane">}} </del> <ins> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} </ins> replaces it with a new one. If you deploy a Pod in a namespace, and you don't
Code change:
No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.

Related discussion:
text: following methods: * [TokenRequest API](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) <del> (recommended): Request a short-lived service account token using your *application code*. The token expires automatically and can rotate upon expiration. </del> <ins> (recommended): Request a short-lived service account token from within your own *application code*. The token expires automatically and can rotate upon expiration. If you have a legacy application that is not aware of Kubernetes, you could use a sidecar container within the same pod to fetch these tokens and make them available to the application workload. </ins> * [Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) <del> (recommended): In Kubernetes v1.20 and later, use the Pod specification to </del> <ins> (also recommended): In Kubernetes v1.20 and later, use the Pod specification to </ins> tell the kubelet to add the service account token to the Pod as a *projected volume*. Projected tokens expire automatically, and the kubelet rotates the token before it expires.