jiebi/CodeConvo huggingface dataset:
Change:
Problem: Incorrect stage values in FeatureGate documentation LegacyNodeRoleBehavior has a stage of as of 1.19, which is not a valid stage. WindowsEndpointSliceProxying has a stage of as of 1.21; all other stage values are capitalized. Feature Until -- -- LegacyNodeRoleBehavior 1.19 WindowsEndpointSliceProxying Proposed Solution: Correct Stage text for listed FeatureGates Page to Update:
~That's not what I see on that page. Can you include a screenshot and confirm the URL you're viewing ?~ ~If possible, it'd be useful to see the HTTP headers that go with the page you screenshotted.~ I see it!
/triage accepted /language en /priority backlog /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 : /triage accepted /language en /priority backlog /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
Thanks
Is the change for from to , to and add to ?
AIUI the change for is: change the column from to and the change for is: change the column from to no other changes needed

Discussion:
| `IPv6DualStack` | `true` | Beta | 1.21 | | | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | | | `LegacyNodeRoleBehavior` | `false` | Alpha | 1.16 | 1.18 | <del> | `LegacyNodeRoleBehavior` | `true` | True | 1.19 |  | </del> <ins> | `LegacyNodeRoleBehavior` | `true` | Beta | 1.19 |  | </ins> | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |

| `WinOverlay` | `false` | Alpha | 1.14 | 1.19 | | `WinOverlay` | `true` | Beta | 1.20 | | | `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | 1.20 | <del> | `WindowsEndpointSliceProxying` | `true` | beta | 1.21 | | </del> <ins> | `WindowsEndpointSliceProxying` | `true` | Beta | 1.21 | | </ins> {{< /table >}} ### Feature gates for graduated or deprecated features
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: There is a duplicate code block in . FYI: is like this: Proposed Solution: Delete one of the duplicate code block. 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
/language en

Discussion:
kubectl port-forward deployment/mongo :27017 ``` <del> The output is similar to this: ``` Forwarding from 127.0.0.1:63753 -> 27017 Forwarding from [::1]:63753 -> 27017 ``` </del> The `kubectl` tool finds a local port number that is not in use (avoiding low ports numbers, because these might be used by other applications). The output is similar to:
Change:
This is a Feature Request translate /docs/concepts/policy/node-resource- into Chinese. What would you like to be /zh/docs/concepts/policy/node-resource-
/triage accepted

Discussion:
<ins> --- title: 节点资源管理器 content_type: concept weight: 50 --- <!-- --- reviewers: - derekwaynecarr - klueska title: Node Resource Managers content_type: concept weight: 50 --- --> <!-- overview --> <!-- In order to support latency-critical and high-throughput workloads, Kubernetes offers a suite of Resource Managers. The managers aim to co-ordinate and optimise node's resources alignment for pods configured with a specific requirement for CPUs, devices, and memory (hugepages) resources. --> Kubernetes 提供了一组资源管理器，用于支持延迟敏感的、高吞吐量的工作负载。 资源管理器的目标是协调和优化节点资源，以支持对 CPU、设备和内存（巨页）等资源有特殊需求的 Pod。 <!-- body --> <!-- The main manager, the Topology Manager, is a Kubelet component that co-ordinates the overall resource management process through its [policy](/docs/tasks/administer-cluster/topology-manager/). The configuration of individual managers is elaborated in dedicated documents: --> 主管理器，也叫拓扑管理器（Topology Manager），是一个 Kubelet 组件， 它通过[策略](/zh/docs/tasks/administer-cluster/topology-manager/)， 协调全局的资源管理过程。 各个管理器的配置方式会在专项文档中详细阐述： <!-- - [CPU Manager Policies](/docs/tasks/administer-cluster/cpu-management-policies/) - [Device Manager](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) - [Memory Manger Policies](/docs/tasks/administer-cluster/memory-manager/) --> - [CPU 管理器策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/) - [设备管理器](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) - [内存管理器策略](/zh/docs/tasks/administer-cluster/memory-manager/) </ins>
Change:
I'm at this page : If I follow the guide with the default configuration it will failed. The config from the webapge but if I remove the line : kubernetesVersion: v1.21 it will works. `
you should use the semver format is being followed by kubeadm and k8s. /kind support /close /sig cluster-lifecycle
Closing this issue. <detailsIn response to : kubernetesVersion: v1.21 /close /sig cluster-lifecycle </details
/reopen /remove-kind support actually...i see that you are reporting this as a problem on the page. we should change -there. /help
Reopened this issue. <detailsIn response to : /reopen /remove-kind support </details
you closed it too fast :) thanks to reopen it. I'll continue to filled issues each time a found a problem (second issue found in two days.. Happy to help the community)
sure, thanks for finding these. /triage accepted
PR is here /remove-help /lifecycle active

Discussion:
# kubeadm-config.yaml kind: ClusterConfiguration apiVersion: kubeadm.k8s.io/v1beta2 <del> kubernetesVersion: v1.21 </del> <ins> kubernetesVersion: v1.21.0 </ins> --- kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1
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

Discussion:
<ins> --- title: "Jobの実行" description: 並列処理を使用してJobを実行します。 weight: 50 --- </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: The feature gate is not listed in Proposed Solution: Add to the feature gate list Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.21 Additional Information: Prompted by /language en /kind bug /sig network
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
we'd like this feature documented, even if it has already graduated

Discussion:
| `EvenPodsSpread` | `true` | Beta | 1.18 | 1.18 | | `EvenPodsSpread` | `true` | GA | 1.19 | - | | `ExecProbeTimeout` | `true` | GA | 1.20 | - | <ins> | `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | </ins> | `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | | `HugePages` | `false` | Alpha | 1.8 | 1.9 |

host mounts, or containers that are privileged or using specific non-namespaced capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled if user namespace remapping is enabled in the Docker daemon. <ins> - `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not applied to Service ExternalIPs. </ins> - `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE. - `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features of normal volumes (can be provided by third-party storage vendors, storage capacity tracking,
Change:
This is a Feature Request Currently only key validity is specified. There is no mention on that e.g. numeric, boolean, list or other types for annotation values are not permitted.
/triage accepted /sig architecture
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /assign

Discussion:
} ``` <ins> {{<note>}} The keys and the values in the map must be strings. In other words, you cannot use numeric, boolean, list or other types for either the keys or the values. {{</note>}} </ins> Here are some examples of information that could be recorded in annotations: * Fields managed by a declarative configuration layer. Attaching these fields
Change:
Page: The second paragraph needs clarity. The QoS class isn't actually used to calculate the pod eviction order, but can be used to estimate the order. The kubelet uses Priority to order pods for out-of-resource eviction. You can use the QoS class to estimate the order in which pods are most likely to get evicted. The kubelet ranks pods for eviction based on the following factors: Whether or not the pod resource usage exceeds the defined requests The pod Priority The amount of the pod's resource consumption relative to the defined requests For more information, see [Evicting end-user pods]. Note: this will likely link to instead of the existing Out of Resource Handling topic. /sig docs /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
/sig node
/triage accepted eh, worth a shot
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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

Discussion:
to schedule the preemptor Pod, or if the lowest priority Pods are protected by `PodDisruptionBudget`. <del> The only component that considers both QoS and Pod priority is [kubelet out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/). The kubelet ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests, then by Priority, and then by the consumption of the starved compute resource relative to the Pods' scheduling requests. See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods) </del> <ins> The kubelet uses Priority to determine pod order for [out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/). You can use the QoS class to estimate the order in which pods are most likely to get evicted. The kubelet ranks pods for eviction based on the following factors: 1. Whether the starved resource usage exceeds requests 1. Pod Priority 1. Amount of resource usage relative to requests See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods) </ins> for more details. kubelet out-of-resource eviction does not evict Pods when their

exceeding its requests, it won't be evicted. Another Pod with higher priority that exceeds its requests may be evicted. ## {{% heading "whatsnext" %}} * Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)
Change:
example commands are missing Resulting in: I will prepare a patch for this.
/triage accepted /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 : /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

Discussion:
{{< tabs name="kubectl_retainkeys_example" >}} {{{< tab name="Bash" codelang="bash" >}} <del> kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)" </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)" </ins> {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} <del> kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) </ins> {{< /tab >}}} {{< /tabs >}}

{{< tabs name="kubectl_retainkeys2_example" >}} {{{< tab name="Bash" codelang="bash" >}} <del> kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)" </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)" </ins> {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} <del> kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw) </del> <ins> kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw) </ins> {{< /tab >}}} {{< /tabs >}}
Change:
example commands are missing Resulting in: I will prepare a patch for this.
/triage accepted /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 : /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

Discussion:
Patch your Deployment: ```shell <del> kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no-retainkeys.yaml </del> <ins> kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-no-retainkeys.yaml </ins> ``` In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`:

Patch your Deployment again with this new patch: ```shell <del> kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-retainkeys.yaml </del> <ins> kubectl patch deployment retainkeys-demo --type strategic --patch-file patch-file-retainkeys.yaml </ins> ``` Examine the content of the Deployment:
Change:
maybe adding an example with data dir for restore
/triage accepted
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:
```shell ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb ``` <ins> Another example for restoring using etcdutl options: ```shell ETCDCTL_API=3 etcdutl --data-dir <data-dir-location> snapshot restore snapshotdb ``` </ins> For more information and examples on restoring a cluster from a snapshot file, see [etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster).
Change:
Page to update: Blocked by Based on in PR , we should add the following information about node conditions to the Taint Nodes by Condition section of this page. The API server also respects when making scheduling decisions. For example, If the node condition is active, the system doesn't allow any new Pods to schedule on the node. If the node condition is active on a node, the system doesn't allow new pods on the node. What is "the system"? The API server? /cc /assign /sig docs /language en
"The system" is a mix of components: the kube-controller-manager sets the taints via the node controller. apiserver sets the toleration for DiskPressure for non-BestEffort pods. scheduler checks if pods have tolerations for the taint But that's too much implementation detail. "The system" or "the control plane" should be enough. WDYT ?
Ah, if it's the control plane then we can say that haha I thought it was something else :P
/triage accepted

Discussion:
## Taint Nodes by Condition <del> The node lifecycle controller automatically creates taints corresponding to Node conditions with `NoSchedule` effect. Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations. </del> <ins> The control plane, using the node {{<glossary_tooltip text="controller" term_id="controller">}}, automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/pod-eviction#node-conditions). The scheduler checks taints, not node conditions, when it makes scheduling decisions. This ensures that node conditions don't directly affect scheduling. For example, if the `DiskPressure` node condition is active, the control plane adds the `node.kubernetes.io/disk-pressure` taint and does not schedule new pods onto the affected node. If the `MemoryPressure` node condition is active, the control plane adds the `node.kubernetes.io/memory-pressure` taint. You can ignore node conditions for newly created pods by adding the corresponding Pod tolerations. The control plane also adds the `node.kubernetes.io/memory-pressure` toleration on pods that have a {{< glossary_tooltip text="QoS class" term_id="qos-class" >}} other than `BestEffort`. This is because Kubernetes treats pods in the `Guaranteed` or `Burstable` QoS classes (even pods with no memory request set) as if they are able to cope with memory pressure, while new `BestEffort` pods are not scheduled onto the affected node. </ins> The DaemonSet controller automatically adds the following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from breaking.

Adding these tolerations ensures backward compatibility. You can also add arbitrary tolerations to DaemonSets. ## {{% heading "whatsnext" %}} * Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it
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: "Not found" / 404 returned by Proposed Solution: Redirect to correct page at Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Info: Was actually testing and trying out some of the redirect rules and saw that these 2 return a 404: Opened a separate issue () for
/assign
Seems like the correct link is
/triage accepted

Discussion:
/docs/home/contribute/generated-reference/kubernetes-components/ /docs/contribute/generate-ref-docs/kubernetes-components/ 301 /docs/home/contribute/localization/ /docs/contribute/localization/ 301 /docs/home/contribute/page-templates/ /docs/contribute/style/page-templates/ 301 <del> /docs/home/contribute/participating/ /docs/contribute/participating/ 301 </del> <ins> /docs/home/contribute/participating/ /docs/contribute/participate/ 301 </ins> /docs/home/contribute/review-issues/ /docs/contribute/intermediate/ 301 /docs/home/contribute/blog-post/ /docs/contribute/start/ 301 /docs/home/contribute/write-new-topic/ /docs/contribute/style/write-new-topic/ 301
Change:
Hi, In this document, In this section It is mentioned that in order to make the metrics-server works probably, you have to edit the ConfigMap as shown But in a kubeadm deployed cluster, there is no key in the ConfigMap .. There is this: Which you can not edit as described in the document. The metrics-server is not working due to this issue..
thanks for the report. the key should be renamed from to in PRs welcome. /triage accepted /sig cluster-lifecycle /kind bug
/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

Discussion:
If you have already created the cluster you must adapt it by doing the following: - Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace. <del> In that ConfigMap, the `config` key has a </del> <ins> In that ConfigMap, the `kubelet` key has a </ins> [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`. - On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml`