jiebi/CodeConvo huggingface dataset:
Change:
<!-- 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 Link to at the end of Make this link particularly prominent. It should come before the other three links in the What's Next section of the page. Why is this needed directs readers to visit However, people who get to the end of do not see any link back to Comments This is a consequence of the Katacoda shutdown - - and our response to that shutdown. /language en /kind feature
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 Proposed fix in
/good-first-issue (retrospectively)

Discussion:
## {{% heading "whatsnext" %}} <ins> * Tutorial to _[deploy your first app on Kubernetes with kubectl](/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/)_. </ins> * Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/). * Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/). * Learn more about [Service objects](/docs/concepts/services-networking/service/).
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 Change to mention the Why is this needed The Kubernetes project provides the descheduler - as an add-on - but our overview of scheduling makes no mention of it. Comments /language en /kind feature /sig scheduling
/priority backlog /triage accepted /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 : /priority backlog /triage accepted /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
/assign RakshitKumar04
Hii, Can you please elaborate, do I just need to add a heading under Scheduling and connect a link to it? !
Contributors are welcome to propose their own way to include the new concept (the descheduler) into the existing page. if you are not sure about how to the new detail, you could consider looking for a different issue. Maybe there is some other work to do that you'd understand better.
IMO, we can make a new heading for descheduler and add a paragraph(some content) for descheduler under it, and link it to the for more information.
Hi, your thoughts on the above opinion?
The approach I recommend is to open a PR and ask for feedback there. I don't see this as being a complicated change.
Thanks for your opinion.

Discussion:
* [Scheduler Performance Tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * [Resource Bin Packing for Extended Resources](/docs/concepts/scheduling-eviction/resource-bin-packing/) * [Pod Scheduling Readiness](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/) <ins> * [Descheduler](https://github.com/kubernetes-sigs/descheduler#descheduler-for-kubernetes) </ins> ## Pod Disruption
Change:
This is a Bug Report Problem: The Feature State for is mentioned as under the docs which is wrong. As per mention in the the correct Feature state for is . Proposed Solution: Update the Feature State of MixedProtocolLBService from Kubernetes v1.24 [beta] to Kubernetes v1.26 [stable]. Page to Update:
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 /sig network
I will open a PR for it soon. /assign
Fixed the issue here:

Discussion:
#### Load balancers with mixed protocol types <del> {{< feature-state for_k8s_version="v1.24" state="beta" >}} </del> <ins> {{< feature-state for_k8s_version="v1.26" state="stable" >}} </ins> By default, for LoadBalancer type of Services, when there is more than one port defined, all ports must have the same protocol, and the protocol must be one which is supported
Change:
This is a Bug Report Problem: The link for under the in is wrong. It is redirected to the instead of that it should redirect to the Proposed Solution: Kubernetes volume plugin should redirect to the instead to the Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig docs /sig storage
I would like to work on it /assign /language en
/triage accepted
This issue is resolved here

Discussion:
persist data. Volume management components are shipped as Kubernetes volume <del> [plugin](/docs/concepts/storage/volumes/#types-of-volumes). </del> <ins> [plugin](/docs/concepts/storage/volumes/#volume-types). </ins> The following broad classes of Kubernetes volume plugins are supported on Windows: * [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexvolume)
Change:
The existing documentation for Topology Aware Routing says however, this was before refactored and fixed the kube-proxy traffic policy problems caused by the lack of definitions on the Service traffic types This caused issues like fixed with , because we have mixed mode, If I understand correctly, right now and are not exclusive, since the former applies the traffic that is originated from "outside the cluster" and the later only applies to the traffic originated within the cluster. If that is correct , we should modify the documentation to say "Topology Aware Hints are not used when internalTrafficPolicy is set to Local on a Service. It is possible to use both features in the same cluster on different Services, just not on the same Service."
/assign /sig network
/retitle Stale docs for topology aware routing constraints
/language en
Thanks for catching this Agree with your proposed fix.
/triage accepted /kind bug
/assign

Discussion:
## Constraints <del> * Topology Aware Hints are not used when either `externalTrafficPolicy` or `internalTrafficPolicy` is set to `Local` on a Service. It is possible to use both features in the same cluster on different Services, just not on the same Service. </del> <ins> * Topology Aware Hints are not used when `internalTrafficPolicy` is set to `Local` on a Service. It is possible to use both features in the same cluster on different Services, just not on the same Service. </ins> * This approach will not work well for Services that have a large proportion of traffic originating from a subset of zones. Instead this assumes that incoming
Change:
This is a Bug Report Problem: The hyperlinks for OpenAPI validation schemas are also published and Validation Schema Publishing under the task page is not working. They both redirect to which is incorrect, the correct one is Proposed Solution: OpenAPI validation schemas are also published and Validation Schema Publishing should redirect to instead of Page to Update:
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
/sig api-machinery /language en /sig docs
Fixed the issue here:

Discussion:
This example turned off client-side validation to demonstrate the API server's behavior, by adding the `--validate=false` command line option. <del> Because the [OpenAPI validation schemas are also published](#publish-validation-schema-in-openapi-v2) </del> <ins> Because the [OpenAPI validation schemas are also published](#publish-validation-schema-in-openapi) </ins> to clients, `kubectl` also checks for unknown fields and rejects those objects well before they would be sent to the API server.

With one of those specification, both an integer and a string validate. <del> In [Validation Schema Publishing](#publish-validation-schema-in-openapi-v2), </del> <ins> In [Validation Schema Publishing](#publish-validation-schema-in-openapi), </ins> `x-kubernetes-int-or-string: true` is unfolded to one of the two patterns shown above. ### RawExtension
Change:
Facing error HorizontalPodAutoscaler.autoscaling "test" is invalid: spec.behavior.scaleDown.policies[0].periodSeconds: Invalid value: 3600: must be less than or equal to 1800 It is a limitation, I'd like to avoid scaling down a maximum of 1 pod every 1 hour not half an hour Add a scale down policy for a periodSeconds of 1 hour If the issue not resolved, better to modify the documentation to clearly mention that this is a limitation and the maximum value of must be less than or equal half an hour <details</details<detailsAWS EKS </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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
/sig Docs
For Reference This is a well-thought-out limit set in this PR:
However, mentioning this in yaml or in a note in the Default behaviour section doesn't sound bad. You can raise the issue in for contribution related help please go through t
Let's move this to k/website /transfer website
/sig autoscaling /kind feature /remove-kind bug
/assign
/triage accepted /priority backlog

Discussion:
``` `periodSeconds` indicates the length of time in the past for which the policy must hold true. <ins> The maximum value that you can set for `periodSeconds` is 1800 (half an hour). </ins> The first policy _(Pods)_ allows at most 4 replicas to be scaled down in one minute. The second policy _(Percent)_ allows at most 10% of the current replicas to be scaled down in one minute.
Change:
The documentation for fails in step 2 for debian based installs (particularly ubuntu 22.04) due to a known issue: The workaround is to use instead of the google url:
Page related to the issue: /language en
/retitle Unable to install kubeadm, kubelet and kubectl on Ubuntu 22.04 due to known GPG key issue
PRs welcome /help /sig cluster-lifecycle /triage accepted
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 : PRs welcome /sig cluster-lifecycle /triage accepted </details
This is working fine for me. Here are the installation logs.
You can't close an active issue/PR unless you authored it or you are a collaborator. <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
Hi try downloading the Kubernetes GPG key and saving it in a location where apt can use it to verify the packages from the Kubernetes repository. You can run the command for same. You can also refer to this comment
it makes sense to update the pages as per the linked comment.
/assign

Discussion:
2. Download the Google Cloud public signing key: ```shell <del> curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg </del> <ins> curl -fsSL https://dl.k8s.io/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg </ins> ``` 3. Add the Kubernetes `apt` repository:
Change:
Under the the is pointing toward the wrong line in the file.
/assign
/retitle Incorrect line reference in within
/triage accepted

Discussion:
## Running the website locally using Hugo <del> Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L10) file. </del> <ins> Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L11) file. </ins> To build and test the site locally, run:
Change:
Here is a statement under the documentation. If more than one default StorageClass is accidentally set, the newest default is used when the PVC is dynamically provisioned. Here is another statement that contradicts with the first one in the documentation. If more than one default is specified, the admission plugin forbids the creation of all PVCs.
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
Pages related to issue: , /language en
/retitle Inconsistencies in default StorageClass behaviour in "Storage Classes" and "Persistent Volumes" pages /sig storage
/sig docs

Discussion:
PVs of that default. Specifying a default StorageClass is done by setting the annotation `storageclass.kubernetes.io/is-default-class` equal to `true` in a StorageClass object. If the administrator does not specify a default, the <del> cluster responds to PVC creation as if the admission plugin were turned off. If more than one default is specified, the admission plugin forbids the creation of all PVCs. </del> <ins> cluster responds to PVC creation as if the admission plugin were turned off. If more than one default StorageClass is specified, the newest default is used when the PVC is dynamically provisioned. </ins> * If the admission plugin is turned off, there is no notion of a default StorageClass. All PVCs that have `storageClassName` set to `""` can be bound only to PVs that have `storageClassName` also set to `""`.
Change:
YAML code examples have a Copy To Clipboard function. This function is broken on several pages. Example: code example in When you click the Copy To Clipboard icon, the following code is copied: which is not correct YAML because of extra indentation on all lines except of the first line: Indentation is broken when element responsible for rendering of code is itself indented, for example when it's part of ordered or unordered list: There are several places like this: and more
The error message "error parsing error converting YAML to JSON: yaml: line 2: mapping values are not allowed in this context" typically indicates a syntax error in your "" file. The error is likely in the second line of the YAML file, where mapping values are not correctly formatted. Here are a few common reasons that can cause this error and how to resolve them: Incorrect YAML Formatting: Make sure your YAML file is correctly formatted. YAML is sensitive to indentation and structure. Ensure that the YAML keys and values are properly indented and aligned. YAML files use spaces for indentation, and each level should be indented by the same number of spaces. Improper Use of Tabs: YAML doesn't support tabs for indentation. Ensure that you are using spaces only for indentation in your YAML file. Unbalanced Quotes: Check if you have any unbalanced quotes (single or double) in your YAML file. Unbalanced quotes can lead to parsing errors. Invalid Characters: Verify that there are no special characters or control characters that might be causing issues in your YAML file. Incorrect Use of Dashes: YAML uses dashes to represent lists. Make sure that you are using the correct syntax for lists if applicable in your "" file. Errors in Line 2: Since the error message points to line 2, double-check that the syntax in line 2 is correct. Ensure that it is a valid YAML key-value pair. To help you further, it would be helpful if you can share the content of your "" file. That way, I can assist you in identifying the specific issue in the YAML file and provide a solution to resolve it.
YAML is correct, it goes directly from But when you use Copy To Clipboard icon on this page and paste it from the clipboard, it gets broken.
I can replicate this. /triage accepted /priority backlog /area web-development

Discussion:
Dieses Lernprogramm enthält ein aus den folgenden Dateien erstelltes Container-Image: <del> {{< codenew language="js" file="minikube/server.js" >}} </del> <ins> {{% codenew language="js" file="minikube/server.js" %}} </ins> <del> {{< codenew language="conf" file="minikube/Dockerfile" >}} </del> <ins> {{% codenew language="conf" file="minikube/Dockerfile" %}} </ins> Weitere Informationen zum `docker build` Befehl, lesen Sie die [Docker Dokumentation](https://docs.docker.com/engine/reference/commandline/build/).
Change:
YAML code examples have a Copy To Clipboard function. This function is broken on several pages. Example: code example in When you click the Copy To Clipboard icon, the following code is copied: which is not correct YAML because of extra indentation on all lines except of the first line: Indentation is broken when element responsible for rendering of code is itself indented, for example when it's part of ordered or unordered list: There are several places like this: and more
The error message "error parsing error converting YAML to JSON: yaml: line 2: mapping values are not allowed in this context" typically indicates a syntax error in your "" file. The error is likely in the second line of the YAML file, where mapping values are not correctly formatted. Here are a few common reasons that can cause this error and how to resolve them: Incorrect YAML Formatting: Make sure your YAML file is correctly formatted. YAML is sensitive to indentation and structure. Ensure that the YAML keys and values are properly indented and aligned. YAML files use spaces for indentation, and each level should be indented by the same number of spaces. Improper Use of Tabs: YAML doesn't support tabs for indentation. Ensure that you are using spaces only for indentation in your YAML file. Unbalanced Quotes: Check if you have any unbalanced quotes (single or double) in your YAML file. Unbalanced quotes can lead to parsing errors. Invalid Characters: Verify that there are no special characters or control characters that might be causing issues in your YAML file. Incorrect Use of Dashes: YAML uses dashes to represent lists. Make sure that you are using the correct syntax for lists if applicable in your "" file. Errors in Line 2: Since the error message points to line 2, double-check that the syntax in line 2 is correct. Ensure that it is a valid YAML key-value pair. To help you further, it would be helpful if you can share the content of your "" file. That way, I can assist you in identifying the specific issue in the YAML file and provide a solution to resolve it.
YAML is correct, it goes directly from But when you use Copy To Clipboard icon on this page and paste it from the clipboard, it gets broken.
I can replicate this. /triage accepted /priority backlog /area web-development

Discussion:
--> У цьому навчальному матеріалі ми використовуємо образ контейнера, зібраний із наступних файлів: <del> {{< codenew language="js" file="minikube/server.js" >}} </del> <ins> {{% codenew language="js" file="minikube/server.js" %}} </ins> <del> {{< codenew language="conf" file="minikube/Dockerfile" >}} </del> <ins> {{% codenew language="conf" file="minikube/Dockerfile" %}} </ins> <!--For more information on the `docker build` command, read the [Docker documentation](https://docs.docker.com/engine/reference/commandline/build/). -->
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 Change to link to Why is this needed This change will help readers to find relevant documentation. Comments /language en /triage accepted /good-first-issue
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 : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Change to link to This change will help readers to find relevant documentation. /language en /triage accepted /good-first-issue 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
This is a good first issue. If you have already worked on an issue for Kubernetes docs, please save this issue for someone who has not.
I would like to work on this issue /assign
:exclamation: please read
I would like to work on this issue /assign
/assign

Discussion:
The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Pod" term_id="mirror-pod" >}} on the Kubernetes API server for each static Pod. This means that the Pods running on a node are visible on the API server, <del> but cannot be controlled from there. </del> <ins> but cannot be controlled from there. See the guide [Create static Pods](/docs/tasks/configure-pod-container/static-pod) for more information. </ins> {{< note >}} The `spec` of a static Pod cannot refer to other API objects