jiebi/CodeConvo huggingface dataset:
Change:
Please change the link at ("Adding Windows nodes" page): with the new one:
Welcome and thanks for the first issue here! I will look into this issue. /assign
/triage accepted /kind bug
Instead you can request a new release in the sig windows tools repo, by logging an issue there. Linking to the master branch there is not a good idea, IMO. /sig windows
Also what problems are you seeing?
The problem is that the link is dead. We need to replace it with the link in
GitHub didn't allow me to assign the following users: steven-my. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign steven-my 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

Discussion:
#### Install wins, kubelet, and kubeadm ```PowerShell <del> curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 </del> <ins> curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 </ins> .PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} ```

#### Install wins, kubelet, and kubeadm ```PowerShell <del> curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 </del> <ins> curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 </ins> .PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD ```
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: kubectl-convert is now a plugin and does not come bundled with kubectl, but the still lists convert as a operation Proposed Solution: Remove the reference of convert from operations Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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
/sig cli
We could also leave it in the table but mark that it depends on an in-tree plugin that you must already have installed onto your client.
/language en
/retitle kubectl command reference page lists “kubectl convert” (which is provided by a plugin)
Sure. I will create a PR for this

Discussion:
`cluster-info`    | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster. `completion`    | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh). `config`        | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details. <del> `convert`    | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. </del> <ins> `convert`    | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. Note - requires `kubectl-convert` plugin to be installed. </ins> `cordon`    | `kubectl cordon NODE [options]` | Mark node as unschedulable. `cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | Copy files and directories to and from containers. `create`        | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin.
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: Static Pods link on page is missing. Proposed Solution: Perhaps one of the followings works. the broken link on certificate renewal page. page Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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 I can work on this.
Fixed it here:

Discussion:
After running the command you should restart the control plane Pods. This is required since dynamic certificate reload is currently not supported for all components and certificates. <del> [Static Pods](/docs/tasks/configure-pod-containerstatic-pod/) are managed by the local kubelet </del> <ins> [Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet </ins> and not by the API Server, thus kubectl cannot be used to delete and restart them. To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/
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 Update to mention and document the label Why is this needed mentions a label but this is not yet mentioned in Comments The whole tree within is deprecated. I'm not sure if the label is as well. /language en /kind feature
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
We should do this /lifecycle frozen /triage accepted
This issue has not been updated in over 1 year, and should be re-triaged. You can: Confirm that this issue is still relevant with (org members only) Close this issue with For more details on the triage process, see /remove-triage accepted
/triage accepted /priority backlog
/assign

Discussion:
and they were applied successfully. For more details, read about [LimitRanges](/docs/concepts/policy/limit-range). <ins> ### addonmanager.kubernetes.io/mode Example: `addonmanager.kubernetes.io/mode: "Reconcile"` Used on: All objects To specify how an add-on should be managed, you can use the `addonmanager.kubernetes.io/mode` label. This label can have one of three values: `Reconcile`, `EnsureExists`, or `Ignore`. - `Reconcile`: Addon resources will be periodically reconciled with the expected state. If there are any differences, the add-on manager will recreate, reconfigure or delete the resources as needed. This is the default mode if no label is specified. - `EnsureExists`: Addon resources will be checked for existence only but will not be modified after creation. The add-on manager will create or re-create the resources when there is no instance of the resource with that name. - `Ignore`: Addon resources will be ignored. This mode is useful for add-ons that are not compatible with the add-on manager or that are managed by another controller. For more details, see [Addon-manager](https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/addon-manager/README.md) </ins> ### beta.kubernetes.io/arch (deprecated) This label has been deprecated. Please use `kubernetes.io/arch` instead.
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 Minikube playground (pages such as ) launches Kubernetes v1.17 This is a shortcoming because there is drift between what we're documenting in pages like , and what actually works in the Katacoda environment. Proposed Solution: Update the Katacoda playground to use a newer version of Minikube and hence a newer Kubernetes cluster version. Page to Update: (and others that use the shortcode) Additional Information: /priority important-longterm
This causes:
/triage accepted
like this:] [URL of the embedded terminal] view- [Content of ] I digged these pages but could not find where to update to change the minikube & K8s version:
do you know / can you recommend someone who can help explain where we might open a PR to update this?
Let me find out for you. The person is away this week so expect a respond next week.
Was there an update on this? Would be happy to help get this updated if needed.
Sorry for the delay. It was caught up with other conversations. I've raised a PR in It will now use K8s 1.20 which is the latest available in Katacoda. I haven't tested the build yet but will do once ready and will update accordingly. Update: Tested the preview build and looks to be working as expected.
I was reffering to minkube version not kubernetes version. is it possible to re-open the this issue
It seems that you have already opened another PR that addresses the Minikube version of Katacoda issue.

Discussion:
{{ if .HasShortcode "kat-button" }} <del> <div id="katacoda-environment" data-katacoda-ondemand="true" data-katacoda-port="30000" data-katacoda-env="minikube" data-katacoda-command="start.sh" data-katacoda-ui="panel"></div> </del> <ins> <div id="katacoda-environment" data-katacoda-ondemand="true" data-katacoda-port="30000" data-katacoda-env="minikube:1.20" data-katacoda-command="start.sh" data-katacoda-ui="panel"></div> </ins> {{ end }} {{ with .Site.Params.algolia_docsearch }} <!-- scripts for algolia docsearch -->
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 Add an entry to the Kubernetes glossary, “Eviction”. Explain how Kubernetes uses this term. There are two flavors of eviction: node-initiated eviction, and API-initiated eviction. The detailed glossary entry should mention both and hyperlink to more detailed articles on these. Why is this needed “eviction” is Kubernetes jargon; readers may well come across the term without recognising it. We have entries for the specific flavors but not an overall entry for the general term. Comments Also see issue /kind feature /language en /priority backlog
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 pages: Scheduling, Preemption and Eviction Node-pressure Eviction API-initiated Eviction
/assign

Discussion:
<ins> --- title: Eviction id: eviction date: 2021-05-08 full_link: /docs/concepts/scheduling-eviction/ short_description: > Process of terminating one or more Pods on Nodes aka: tags: - operation --- Eviction is the process of terminating one or more Pods on Nodes. <!--more--> There are two kinds of eviction: * [Node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) * [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) </ins>
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: In the section of the , the second paragraph's first sentence is mixed up: I've bolded the part of the sentence that is mixed up. A declarative API does not keep the current state of objects in sync with desired state. The controller/reconciler does that. Proposed Solution: Rework the wording above to the following: 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
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]:

Discussion:
When you combine a custom resource with a *custom controller*, custom resources provide a true _declarative API_. <del> A [declarative API](/docs/concepts/overview/kubernetes-api/) allows you to _declare_ or specify the desired state of your resource and tries to keep the current state of Kubernetes objects in sync with the desired state. The controller interprets the structured data as a record of the user's desired state, and continually maintains this state. </del> <ins> The Kubernetes [declarative API](/docs/concepts/overview/kubernetes-api/) enforces a separation of responsibilities. You declare the desired state of your resource. The Kubernetes controller keeps the current state of Kubernetes objects in sync with your declared desired state. This is in contrast to an imperative API, where you *instruct* a server what to do. </ins> You can deploy and update a custom controller on a running cluster, independently of the cluster's lifecycle. Custom controllers can work with any kind of resource,
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: ] ] Proposed Solution: Page to Update: - <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko /good-first-issue
This request has been marked as suitable for new contributors. 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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: A request with a decimal point, like , is converted to by the API, and precision finer than is not allowed. For this reason, the form might be preferred. API , . , . API , . , . - <!--Kubernetes Version:--/good-first-issue </details
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

Discussion:
컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. <del> `0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 로 변환되며, `1m` 도 허용되지 않게 정밀하다. 이러한 이유로, `100m` 형식이 선호될 수 있다. </del> <ins> `0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, `1m` 보다 더 정밀한 단위는 허용되지 않는다. 이러한 이유로, `100m` 과 같은 형식이 선호될 수 있다. </ins> CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. 0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다.
Change:
The following information was dropped in and is critical to include in the garbage collection ownerReferences topic:
/triage accepted /sig api-machinery
/priority important-soon

Discussion:
an owner reference. Owner references help different parts of Kubernetes avoid interfering with objects they don’t control. <ins> {{< note >}} Cross-namespace owner references are disallowed by design. Namespaced dependents can specify cluster-scoped or namespaced owners. A namespaced owner **must** exist in the same namespace as the dependent. If it does not, the owner reference is treated as absent, and the dependent is subject to deletion once all owners are verified absent. Cluster-scoped dependents can only specify cluster-scoped owners. In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner, it is treated as having an unresolvable owner reference, and is not able to be garbage collected. In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`, or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported. You can check for that kind of Event by running `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. {{< /note >}} </ins> ## Cascading deletion {#cascading-deletion} Kubernetes checks for and deletes objects that no longer have owner

dependent resources, based on the delete permissions of the owner. This control prevents unauthorized users from delaying owner object deletion. <ins> {{< note >}} Cross-namespace owner references are disallowed by design. Namespaced dependents can specify cluster-scoped or namespaced owners. A namespaced owner **must** exist in the same namespace as the dependent. If it does not, the owner reference is treated as absent, and the dependent is subject to deletion once all owners are verified absent. Cluster-scoped dependents can only specify cluster-scoped owners. In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner, it is treated as having an unresolvable owner reference, and is not able to be garbage collected. In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`, or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported. You can check for that kind of Event by running `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. {{< /note >}} </ins> ## Ownership and finalizers When you tell Kubernetes to delete a resource, the API server allows the
Change:
Problem: The sentence below in the README- seems to be incomplete "अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।" the first part i.e "अपने fork में कोई भी परिवर्तन करना चाहते हैं" makes no proper connection with the other part
/assign
We always like to have better sentence structure. What solution do you recommend?
/language hi /retitle [hi] Fix README-
I think starting the statement with " इस fork में आप अपने इच्छा अनुसार परिवर्तन कर सकते है " would sound more correct as well as it would go with the flow with the entire statement
We need to mean the same as
अपने fork में कोई भी परिवर्तन करना चाहते हैं (existing one) -this means "want to make any changes to your fork" which is a kind of question to user while we want to convey a assertive sentence that developers can make changes to their fork if you get what I mean
Exactly, we need to mean . You can refer the version I stated above. Using seems unnecessary, is more straight forward.
"want to make any changes to your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it. " this is what the (hi) translation sounds to me I guess that is abrupt and if you want then we can go for " इस fork में आप बदलाव कर सकते है "
How about "अपने fork ~के~ में परिवर्तन करने के में बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं"
perfect to me
Thanks, I see you have assigned yourself. You can make a PR.
if you want you can go with your PR what say ?
Why did you unassign. You can make a PR, else this could be a with some tweaks to issue description.
/triage accepted
/assign
Reopened this issue. <detailsIn response to : /reopen 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
You need to PR to for things to change here. /reopen

Discussion:
## डॉक्स में योगदान देना <del> आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं। </del> <ins> आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में परिवर्तन करने के बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं। </ins> एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।**
Change:
There's a broken link on this page pointing to: It's in the first paragraph under:
I'm seeing the same. Looks like it should probably link over to: . Does that make sense to you as well?
Yeah I think that's probably what the original author intended
/sig security auth /kind bug /triage accepted /language en

Discussion:
You can define _exemptions_ from pod security enforcement in order allow the creation of pods that would have otherwise been prohibited due to the policy associated with a given namespace. Exemptions can be statically configured in the <del> [Admission Controller configuration](#configuring-the-admission-controller). </del> <ins> [Admission Controller configuration](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller). </ins> Exemptions must be explicitly enumerated. Requests meeting exemption criteria are _ignored_ by the Admission Controller (all `enforce`, `audit` and `warn` behaviors are skipped). Exemption dimensions include: