jiebi/CodeConvo huggingface dataset:
Code change:
found typo "ontrolPlaneEndpoint" in the below <img width="862" alt="typo ontrolPlaneEndpoint" src=""There is a typo "ontrolPlaneEndpoint" in the localAPIEndpoint description it should be "controlPlaneEndpoint"
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Page related to issue: /language en
/retitle Typo in auto-generated "kubeadm Configuration (v1beta4)" reference page
The mentioned reference page for "kubeadm Configuration (v1beta4)" is . The page is generated from the upstream source code . As the page is generated from the upstream source code, any fixes would need to be addressed there. For those interested in contributing to resolve this issue, please refer to the upstream contribution guidelines outlined at:
/sig docs
this is not a typo in the code files and also in my browser it's shown as controlPlaneEndpoint, so maybe it's a rendering issue. ! cc
but again, there are no typos in the code / go docs. also NOTE that v1beta4 is WIP API that should not be used yet by users.
the in is also dropped in another place on that page, screenshot below. I'm not familiar with the autogeneration for these pages, is there some processing on the word that is dropping letters when converting from the original? Looks like in the source file its written with a capital and in the generated file its with a lower case. Not sure why it would only so it sometimes though. We should check to see if this is happening on other pages. /priority awaiting-more-evidence <img width="789" alt="Screenshot 2024-03-27 at 9 44 26 AM" src=""
Another interesting observation looking at the - it appears to only happen on the v1beta4 version of the docs, not the previous versions. Looks like it was modified with .
Put up a fix in . It looks like this wasn't from an autogeneration error and just a simple typo when the docs were updated for v1beta4.

Related discussion:
text: <code>string</code> </td> <td> <del> <p><code>ontrolPlaneEndpoint</code> sets a stable IP address or DNS name for the control plane; </del> <ins> <p><code>controlPlaneEndpoint</code> sets a stable IP address or DNS name for the control plane; </ins> It can be a valid IP address or a RFC-1123 DNS subdomain, both with optional TCP port. In case the <code>controlPlaneEndpoint</code> is not specified, the <code>advertiseAddress</code> + <code>bindPort</code> are used; in case the <code>controlPlaneEndpoint</code> is specified but without a TCP port,
Code change:
found typo "ontrolPlaneEndpoint" in the below <img width="862" alt="typo ontrolPlaneEndpoint" src=""There is a typo "ontrolPlaneEndpoint" in the localAPIEndpoint description it should be "controlPlaneEndpoint"
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Page related to issue: /language en
/retitle Typo in auto-generated "kubeadm Configuration (v1beta4)" reference page
The mentioned reference page for "kubeadm Configuration (v1beta4)" is . The page is generated from the upstream source code . As the page is generated from the upstream source code, any fixes would need to be addressed there. For those interested in contributing to resolve this issue, please refer to the upstream contribution guidelines outlined at:
/sig docs
this is not a typo in the code files and also in my browser it's shown as controlPlaneEndpoint, so maybe it's a rendering issue. ! cc
but again, there are no typos in the code / go docs. also NOTE that v1beta4 is WIP API that should not be used yet by users.
the in is also dropped in another place on that page, screenshot below. I'm not familiar with the autogeneration for these pages, is there some processing on the word that is dropping letters when converting from the original? Looks like in the source file its written with a capital and in the generated file its with a lower case. Not sure why it would only so it sometimes though. We should check to see if this is happening on other pages. /priority awaiting-more-evidence <img width="789" alt="Screenshot 2024-03-27 at 9 44 26 AM" src=""
Another interesting observation looking at the - it appears to only happen on the v1beta4 version of the docs, not the previous versions. Looks like it was modified with .
Put up a fix in . It looks like this wasn't from an autogeneration error and just a simple typo when the docs were updated for v1beta4.

Related discussion:
text: <td> <p><code>localAPIEndpoint</code> represents the endpoint of the API server instance that's deployed on this control plane node. In HA setups, this differs from <code>ClusterConfiguration.controlPlaneEndpoint</code> <del> in the sense that <code>ontrolPlaneEndpoint</code> is the global endpoint for the cluster, which then </del> <ins> in the sense that <code>controlPlaneEndpoint</code> is the global endpoint for the cluster, which then </ins> loadbalances the requests to each individual API server. This configuration object lets you customize what IP/DNS name and port the local API server advertises it's accessible on. By default, kubeadm tries to auto-detect the IP of the default
Code change:
chapter refers to the Memory QoS feature but pointing ; link should be updated to point to feature description in k8s official documentation.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Page reported in issue: /language en
I would like to work on this issue.
/assign
The issue is fixed .

Related discussion:
text: Some Kubernetes features exclusively use cgroup v2 for enhanced resource management and isolation. For example, the <del> [MemoryQoS](/blog/2021/11/26/qos-memory-resources/) feature improves memory QoS </del> <ins> [MemoryQoS](/docs/concepts/workloads/pods/pod-qos/#memory-qos-with-cgroup-v2) feature improves memory QoS </ins> and relies on cgroup v2 primitives.
Code change:
in
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en /sig docs
I would to like to work on this issue.
/assign
The issue is fixed .

Related discussion:
text: returned. In this case, the client will need to start from the beginning or omit the `limit` parameter. <del> For example, if there are 1,253 pods on the cluster and you wants to receive chunks </del> <ins> For example, if there are 1,253 pods on the cluster and you want to receive chunks </ins> of 500 pods at a time, request those chunks as follows: 1. List all of the pods on a cluster, retrieving up to 500 pods each time.
Code change:
This is a Bug Report In Kubernetes Training page in hindi the link is not valid which do not show the several Kubernetes Training Partners. <!-- 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 embedded link is not valid. ! Proposed Solution: Update with the valid link Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language hi /sig docs /assign
/area localization
/triage accepted
This issue is resolved under pull request
so i am closing this issue marking as resolved and completed
/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

Related discussion:
text: </center> </div> <div class="main-section landscape-section"> <del> {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}} </del> <ins> {{< cncf-landscape helpers=false category="special--kubernetes-training-partner" >}} </ins> </div> </div>
Code change:
Hello! in the Pod OS section of this page, it says: ... **Editing for clarity: Forgive me if I'm misunderstanding, but kube-scheduler should pick a node for the Pod to run on, and not the other way around? The way the above sentence is worded sounds like kube-scheduler picks Pods to run nodes.
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
these two statements donot contradict as first one say that selecton of node by kube-scheduler is not based on . kube-scheduler pick a node of run based on various other creterias but not consider frield
I think you might correct the text might need some correction.
Let me see if I can help with this. /assign

Related discussion:
text: In Kubernetes v{{< skew currentVersion >}}, the value of `.spec.os.name` does not affect how the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} <del> picks a Pod to run a node. In any cluster where there is more than one operating system for </del> <ins> picks a node for the Pod to run on. In any cluster where there is more than one operating system for </ins> running nodes, you should set the [kubernetes.io/os](/docs/reference/labels-annotations-taints/#kubernetes-io-os) label correctly on each node, and define pods with a `nodeSelector` based on the operating system
Code change:
Hello! in the Pod OS section of this page, it says: ... **Editing for clarity: Forgive me if I'm misunderstanding, but kube-scheduler should pick a node for the Pod to run on, and not the other way around? The way the above sentence is worded sounds like kube-scheduler picks Pods to run nodes.
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
these two statements donot contradict as first one say that selecton of node by kube-scheduler is not based on . kube-scheduler pick a node of run based on various other creterias but not consider frield
I think you might correct the text might need some correction.
Let me see if I can help with this. /assign

Related discussion:
text: * [Borg](https://research.google.com/pubs/pub43438.html) * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) * [Omega](https://research.google/pubs/pub41684/) <del> * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). </del>  No newline at end of file <ins> * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). </ins>
Code change:
This is a Feature Request What would you like to be Set a banner to announce KubeCon 2024 NA Why is this needed We usually turn on a banner for the upcoming KubeCon about 4 weeks ahead of the event. Logos are available from: (Note: be sure to copy the logo into this repo) should help with text. Also see the config from a last year's KubeCon. Comments This change will need approval. I would like to set the banner to start on the ~Oct 14, 2024~ Sep 30 and to end on Nov 15, 2024 at 1800 CET (UTC+1). edit: We've been asked if we can do a 6 week banner rather than a 4 week run. /priority important-soon
/triage accepted
/assign
/assign

Related discussion:
text: <a href= "https://events.linuxfoundation.org/kubecon-cloudnativecon-open-source-summit-ai-dev-china/register/?utm_source=kubernetes&utm_medium=all&utm_campaign=kubeconcn24&utm_content=slim-banner"> Buy your ticket now! 21 - 23 August | Hong Kong </a> <ins> - name: KubeCon 2024 NA startTime: 2024-09-30T00:00:00  #Added in https://github.com/kubernetes/website/pull/48086 endTime: 2024-11-15T18:00:00 style: >- background: linear-gradient(90deg, rgba(64,66,169,1) 60%, rgba(0,81,181,1) 100%); color: #fffff; title: | <img src ="/images/announcements/kccnc-na-2024-white.svg" style="float: right; height: 100px;" /> <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/">KubeCon + CloudNativeCon 2024</a> message: | Join us for three days of incredible opportunities to collaborate, learn and share with the cloud native community.<br/> <a href= "https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/register/?utm_source=kubernetes&utm_medium=homepage&utm_campaign=KubeCon-NA-2024&utm_content=top-banner"> Buy your ticket now! 12 - 15 November | Salt Lake City </a> </ins>