jiebi/CodeConvo huggingface dataset:
Code change:
{ type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

Related discussion:
text: <!-- 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: Page url: in line 83, click PetSets guide occur 404 error. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Fixed.
Code change:
{ type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

Related discussion:
text: This is a... [ ] Feature Request [X] Bug Report Problem: link "Minikube installation guide" points to which is 404 Proposed Solution: fix the link by making it absolute: Page to Update:
Fixed.
Code change:
{ type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

Related discussion:
text: <!-- 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: Multiple links on the page generate 404 Not Found Examples: (redirected from ) (redirected from ) Proposed Solution: fix the links Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Here is the full list of broken links on xhyve driver kvm (driver installation) xhyve (driver installation) See DRIVERS docker-env command minikube start minikube stop minikube delete full CLI docs
Code change:
{ type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

Related discussion:
text: I wish /docs/user-guide/horizontal-pod-autoscaling/walkthrough/ actually contained the information, or at least a link to autoscaling by custom application logic (as referred to by the first sentence in the article - . The second half of this article seems like the correct target link -
Fixed. Thanks.
Code change:
例如：要禁用batch/v1，请设置 `--runtime-config=batch/v1=false`，以启用batch/v2alpha1，请设置`--runtime-config=batch/v2alpha1`。 该标志接受描述apiserver的运行时配置的逗号分隔的一组键值对。 <del> 重要：启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。 </del> <ins> {{< note >}} 启用或禁用组或资源需要重新启动apiserver和控制器管理器来使得 `--runtime-config` 更改生效。 {{< /note >}} </ins> <!-- <del> ## Enabling resources in the groups </del> <ins> ## Enabling specific resources in the extensions/v1beta1 group DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default. For example: to enable deployments and daemonsets, set `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`. </ins> <del> DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs and ReplicaSets are enabled by default. Other extensions resources can be enabled by setting `--runtime-config` on apiserver. `--runtime-config` accepts comma separated values. For example: to disable deployments and ingress, set `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false` </del> <ins> Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons. </ins> --> <del> ## 启用组中资源 </del> <ins> ## 启用 extensions/v1beta1 组中资源 在 `extensions/v1beta1` API 组中，DaemonSets，Deployments，StatefulSet, NetworkPolicies, PodSecurityPolicies 和 ReplicaSets 是默认禁用的。 例如：要启用 deployments 和 daemonsets，请设置 `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`。 {{< note >}} 出于遗留原因，仅在 `extensions / v1beta1` API 组中支持各个资源的启用/禁用。 </ins> <del> DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs 和 ReplicaSets是默认启用的。 其他扩展资源可以通过在apiserver上设置 `--runtime-config` 来启用。 `--runtime-config` 接受逗号分隔的值。 例如：要禁用 Deployment 和 Ingress， 请设置 `--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingress=false` </del> <ins> {{< /note >}} </ins> {{% /capture %}}

Related discussion:
text: This is a Feature Request Since v1.16, extensions/v1beta1 has been deleted and it should not be used in docs What would you like to be The following pages should be edited due to this deletion. [ ] [ ] [x] [ ] [ ] [ ] [ ] [ ] [x] [x] Why is this needed extensions/v1beta1 is deleted in 1.16 Comments
/kind cleanup /priority important-soon (I think)
If you are looking at this as potentially something to contribute to, it's OK to suggest a PR that fixes only one page, or only some pages. If you do that please mention “Partial fix for issue ” in the description of your PR.
thanks for contribution here. Could you please share which pages would you take? Let us make the assignment more clear and help other contributors easily start their work.
Thank you for your comments. I wrote the target file into PR titles. And I will write to the comment about netlify demo pages and original pages to enable checking the diff easily.
Code change:
### Calico <del> [Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement. </del> <ins> [Calico](https://projectcalico.docs.tigera.io/about/about-calico/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement. </ins> ### Cilium

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 , update the link URL from to update the link URL from to update the link URL from to update the link URL from to update the link URL from to update the link URL from to Why is this needed redirects to , which is a fork of and currently 62 commits behind . The latest commit of : on 29 Oct 2021 The latest commit of : on 12 Feb 2019 and for other CNIs, it would be better to use the final URLs than using redirecting URLs. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Page to update:
/assign
/triage accepted /kind cleanup
/retitle Fix incorrect / outdated URIs in list of network plugins /language en /priority backlog
Code change:
--- <del> title: Control Plane </del> <ins> title: Ambiente de gerenciamento </ins> id: control-plane date: 2020-04-19 full_link:

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: is giving 404 Proposed Solution: if doesn't have the pt version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
Code change:
is an [Istio](https://istio.io/) based ingress controller. * The [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme) is an ingress controller driving [Kong Gateway](https://konghq.com/kong/). <del> * The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller) </del> <ins> * The [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/) </ins> works with the [NGINX](https://www.nginx.com/resources/glossary/nginx/) webserver (as a proxy). * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP router and reverse proxy for service composition, including use cases like Kubernetes Ingress, designed as a library to build your custom proxy. * The [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) is an

Related discussion:
text: "The works with the NGINX webserver (as a proxy)." The URL given against the text "NGINX Ingress Controller for Kubernetes" is not working. It returned 404 error(Page not found) in my case.
/triage accepted /kind cleanup
Code change:
The Kubernetes project recommends that you use the TokenReview API, because this method invalidates tokens that are bound to API objects such as Secrets, ServiceAccounts, and Pods when those objects are deleted. For example, if you <del> delete the Pod that contains a projected ServiceAccount token, the TokenReview API invalidates that token immediately. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </del> <ins> delete the Pod that contains a projected ServiceAccount token, the cluster invalidates that token immediately and a TokenReview immediately fails. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </ins> Your application should always define the audience that it accepts, and should check that the token's audiences match the audiences that the application expects. This helps to minimize the scope of the token so that it can only be <del> used in your appplication and nowhere else. </del> <ins> used in your application and nowhere else. </ins> ## Alternatives

Related discussion:
text: 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.
Code change:
```shell sudo systemctl daemon-reload <del> sudo systemctl enable crio --no </del> <ins> sudo systemctl enable crio --now </ins> ``` <!--

Related discussion:
text: ! w sudo systemctl enable crio --now
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 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: Typo in zh/docs/setup/production-environment/container-runtimes Proposed Solution: -Page to Update: zh: (en: ) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/retitle [zh] Typo in docs/setup/production-environment/container-runtimes /kind bug /language zh
Page is a little bit lagging behind. Will fix. /assign
Code change:
### Preparing the hosts <ins> #### Component installation </ins> Install a {{< glossary_tooltip term_id="container-runtime" text="container runtime" >}} and kubeadm on all the hosts. For detailed instructions and other prerequisites, see [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).

Related discussion:
text: I have a catastrophic problem with my production control-plane just because I naive believe in the instruction of the output of . My control-plane was gone and I couldn't recover from the failure because could not restart. After some tests, I found that need to be so that it tell the to use the correct internal IP that allow both new control plane and the current plane to talk to each other. Specifically, those IPs should allow etcd to communicate throw both servers. Without the default IP interface was used, but the firewall that I set on the default IP did not allow etcd to connect through. At this point, I would like to make a change to the document in a way that it emphasize the importance of in the command.
/language en /sig docs /kind feature
Page reported in issue: /sig cluster-lifecycle
/retitle Highlight the significance of in kubeadm join for HA cluster setup
all k8s components work like that. not only kubeadm. if you want custom IP from a different interface you need to pass it to the advertise address flag, but also as --node-ip to the kubelet. overall this setup with private IPs is not recommended and is difficult to manage. instead you should make the setup so that the public IP is the default route. then firewall the cluster properly. PRs for the above "create cluster" page with a note fix are welcome. the note can talk about "init" and "join", public IPs and firewall. /help /sig network
/triage accepted
actually, let me try to send the note. /remove-help
/assign
Code change:
{{% /tab %}} {{< /tabs >}} <del> #### systemd {#containerd-systemd} </del> <ins> #### Using the `systemd` cgroup driver {#containerd-systemd} </ins> To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set

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 The documentation for container runtimes at: needs to have a clear warning that by adding the suggested change in , this will actually PREVENT from successfully initializing a cluster (this is my experience multiple times with K8s 1.20.4 on Ubuntu 20.04 with containerd - not Docker). Why is this needed The current wording does not indicate that the suggested change for containerd's will actually break things. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --It is not clear even why that suggestion is there given that it stops from working.
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
The current text reads: How would you reword this How about: When using kubeadm, you must manually configure the cgroup driver for kubelet. /language en /priority awaiting-more-evidence /sig cluster-lifecycle
Thank you for all the work that you do, related to Kubernetes and all other open source projects you contribute to. Your efforts are really appreciated. My own experience is that the configuration snippet there is actually harmful in the scope of using kubeadm. I realize now that the page is discussing how to use containerd with the systemd cgroup driver in general... but the typical person coming to the "" documentation is there to learn how to use containerd in the context of kubernetes. That makes that configuration snippet a bit out of place since it will actually prevent the usage of kubeadm. For this reason, I believe it is better to be crystal clear and explicitly mention all of that. "To use the systemd cgroup driver... [plugins... ... SystemdCgroup = true However, when using kubeadm to initialize the cluster, the above configuration should NOT be done (it will actually prevent kubelet from bringing up static pods).
Code change:
{{% /tab %}} {{< /tabs >}} <del> #### systemd {#containerd-systemd} </del> <ins> #### Using the `systemd` cgroup driver {#containerd-systemd} </ins> To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, set

Related discussion:
text: Instead, manually configure the cgroup driver for kubelet."
i don't see anything invalid on the page, but ideas for clarification are welcome. When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager ... ^ the above already explains when the systemd driver is needed. it is the opposite. if you are using kubeadm, you must configure containerd with . and then pass the same driver to the kubelet as explained here: cgroup drivers have been confusing users for a long time and this is really a problem in the CRI spec. there is a plan to automatically handle them but this might take a while to complete.
this area of the docs is seeing some refactor, so you can add comments here too:
This is the source of our difference:. I have tried that setting multiple times (at least 4 times). It does NOT work for me on Ubuntu 20.04. When I do NOT specify that setting in containerd's , then and ONLY THEN does it work... for me.
i just tried following our documentation for installing containerd / installing kubeadm / creating kubeadm cluster. everything works fine for me: also a number of different CI setups are running kubeadm like so, you must be failing something in your setup. i doubt this is a containerd / OS bug of sorts, but it could be. /kind support
did you restart containerd after you : the step here should be after the driver is changed, so that's a documentation problem:
opened PR for this: (it also closes this issue)
Code change:
```shell kubectl apply -f myapp.yaml ``` <ins> 実行結果は下記のようになります。 </ins> ``` pod/myapp-pod created ```

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. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/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:
A `csi` volume can be used in a Pod in three different ways: * through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim) <del> * with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) * with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) </del> <ins> * with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) * with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) </ins> if the driver supports that (beta feature) The following fields are available to storage administrators to configure a CSI

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: Links to some ephemeral volume types are wrong. Proposed Solution: In , update links as follows: → → Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /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