jiebi/CodeConvo huggingface dataset:
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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate docs/concepts/server-networking/server-traffic-policy into Japanese Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted

Discussion:
<ins> --- reviewers: - maplain title: サービス内部トラフィックポリシー content_type: concept weight: 45 --- <!-- overview --> {{< feature-state for_k8s_version="v1.21" state="alpha" >}} *サービス内部トラフィックポリシー*を使用すると、内部トラフィック制限により、トラフィックが発信されたノード内のエンドポイントにのみ内部トラフィックをルーティングできます。 ここでの「内部」トラフィックとは、現在のクラスターのPodから発信されたトラフィックを指します。これは、コストを削減し、パフォーマンスを向上させるのに役立ちます。 <!-- body --> ## ServiceInternalTrafficPolicyの使用 `ServiceInternalTrafficPolicy` [feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にすると、`.spec.internalTrafficPolicy`を`Local`に設定して、{{< glossary_tooltip text="Service" term_id="service" >}}内部のみのトラフィックポリシーを有効にすることができます。 これにより、kube-proxyは、クラスター内部トラフィックにノードローカルエンドポイントのみを使用するようになります。 {{< note >}} 特定のServiceのエンドポイントがないノード上のPodの場合、Serviceに他のノードのエンドポイントがある場合でも、Serviceは(このノード上のポッドの)エンドポイントがゼロであるかのように動作します。 {{< /note >}} 次の例は、`.spec.internalTrafficPolicy`を`Local`に設定した場合のServiceの様子を示しています： ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 internalTrafficPolicy: Local ``` ## 使い方 kube-proxyは、`spec.internalTrafficPolicy`の設定に基づいて、ルーティング先のエンドポイントをフィルタリングします。 `Local`に設定されている場合、ノードのローカルエンドポイントのみが考慮されます。`Cluster`であるか欠落している場合、すべてのエンドポイントが考慮されます。 `ServiceInternalTrafficPolicy`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効な場合、`spec.internalTrafficPolicy`のデフォルトは"Cluster"です。 ## 制約 * Serviceで`externalTrafficPolicy`が`Local`に設定されている場合、サービス内部トラフィックポリシーは使用されません。同じServiceだけではなく、同じクラスター内の異なるServiceで両方の機能を使用することができます。 ## {{% heading "whatsnext" %}} * [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints)を読む * [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)を読む * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む </ins>
Change:
The concept of the has not been introduced at this point yet, but is used at multiple locations on this page. It would make sense to briefly explain what that is and link to a page that covers that topic.
/triage accepted /language en /help I would use a here. We should also mention that StatefulSet is just an example. Related, the example manifest is incomplete. We should add a comment in YAML to make it clear that this is an excerpt.
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 : /triage accepted /language en /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
I would like to fix this /assign
I think is already defined .
My idea is to reference that definition into (see PR )

Discussion:
| `app.kubernetes.io/managed-by`      | The tool being used to manage the operation of an application | `helm` | string | | `app.kubernetes.io/created-by`      | The controller/user who created this resource | `controller-manager` | string | <del> To illustrate these labels in action, consider the following StatefulSet object: </del> <ins> To illustrate these labels in action, consider the following {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} object: </ins> ```yaml <ins> # This is an excerpt </ins> apiVersion: apps/v1 kind: StatefulSet metadata:
Change:
I am being shown on the page. This is in the last paragraph before the API heading. This may be a small bug and can be removed easily in the text. I can see this both on Chrome and Mozilla Firefox on Ubuntu 20.04. Attaching a Screenshot. Look at the bottom right in this image. ! PS. I can look into this.
/triage accepted /kind bug /good-first-issue looks like a problem with
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 : /triage accepted /kind bug /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
/assign

Discussion:
[gRPC](https://grpc.io) protocol for the communication between the [cluster components](/docs/concepts/overview/components/#node-components) {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and <del> ￼{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. </del> <ins> {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. </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 field is written, incorrectly, as (in some places). Proposed Solution: Fix the capitalization to camelCase. /sig scheduling Relevant as there's a plan to the feature. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog
/triage accepted
/cc
/assgin
PR for GA list here:
(In my view), should wait for to merge.
Yes, I will add in to wait.

Discussion:
{{< feature-state for_k8s_version="v1.19" state="beta" >}} <del> Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue </del> <ins> Pods with `preemptionPolicy: Never` will be placed in the scheduling queue </ins> ahead of lower-priority pods, but they cannot preempt other pods. A non-preempting pod waiting to be scheduled will stay in the scheduling queue,

Non-preempting pods may still be preempted by other, high-priority pods. <del> `PreemptionPolicy` defaults to `PreemptLowerPriority`, </del> <ins> `preemptionPolicy` defaults to `PreemptLowerPriority`, </ins> which will allow pods of that PriorityClass to preempt lower-priority pods (as is existing default behavior). <del> If `PreemptionPolicy` is set to `Never`, </del> <ins> If `preemptionPolicy` is set to `Never`, </ins> pods in that PriorityClass will be non-preempting. An example use case is for data science workloads. A user may submit a job that they want to be prioritized above other workloads, but do not wish to discard existing work by preempting running pods. <del> The high priority job with `PreemptionPolicy: Never` will be scheduled </del> <ins> The high priority job with `preemptionPolicy: Never` will be scheduled </ins> ahead of other queued pods, as soon as sufficient cluster resources "naturally" become free.
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 and , links go to , which is wrong. They should go to . Proposed Solution: Find , and replace with . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /kind cleanup /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 Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: In and , Find , and replace with . Page to Update: <!--Kubernetes Version:--/language en /kind cleanup /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
/assign
/triage accepted
/assign

Discussion:
To apply: 1. Open a pull request that adds your GitHub user name to a section of the <del> [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) file </del> <ins> [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file </ins> in the `kubernetes/website` repository. {{< note >}}

To apply: 1. Open a pull request adding yourself to a section of the <del> [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) </del> <ins> [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) </ins> file in the `kubernetes/website` repository. {{< note >}}
Change:
This is an Enhancement 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. --Add "event" entry to the Kubernetes . Why is this needed s are referenced several times in other definitions, but it is not itself defined.
Caution for people working on this: there is an API in and there is also an audit Event type in . The glossary entry should help readers who are confused between the two /language en /triage accepted
/assign I would like to work on this
Awesome, thanks

Discussion:
<ins> --- title: Event id: event date: 2022-01-16 full_link: /docs/reference/kubernetes-api/cluster-resources/event-v1/ short_description: > A report of an event somewhere in the cluster. It generally denotes some state change in the system. aka: tags: - core-object - fundamental --- Each Event is a report of an event somewhere in the {{< glossary_tooltip text="cluster" term_id="cluster" >}}. It generally denotes some state change in the system. <!--more--> Events have a limited retention time and triggers and messages may evolve with time. Event consumers should not rely on the timing of an event with a given reason reflecting a consistent underlying trigger, or the continued existence of events with that reason. Events should be treated as informative, best-effort, supplemental data. In Kubernetes, [auditing](/docs/tasks/debug-application-cluster/audit/) generates a different kind of Event record (API group `audit.k8s.io`). </ins>
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 Tell readers where they can find container images for components of Kubernetes. Why is this needed It's possible to run components of Kubernetes using containers; in fact, as a project we recommend this. However if you try to find where those images are using a search engine and plausible search queries, you don't find that information. Comments Relevant to and to /sig release
/triage accepted
Extra credit: update to link to the new text.
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
is somewhat relevant.
/assign

Discussion:
You can [download Kubernetes](/releases/download/) to deploy a Kubernetes cluster on a local machine, into the cloud, or for your own datacenter. <ins> Several [Kubernetes components](/docs/concepts/overview/components/) such as `kube-apiserver` or `kube-proxy` can also be deployed as [container images](/releases/download/#container-images) within the cluster. It is **recommended** to run Kubernetes components as container images wherever that is possible, and to have Kubernetes manage those components. Components that run containers - notably, the kubelet - can't be included in this category. </ins> If you don't want to manage a Kubernetes cluster yourself, you could pick a managed service, including [certified platforms](/docs/setup/production-environment/turnkey-solutions/). There are also other standardized and custom solutions across a wide range of cloud and
Change:
this documentation is so confusing.... Why section for Draining a node is in the middle when we talk about it at the begining? How one would drain first master node? After 'sudo kubeadm upgrade apply'?
/language en /sig cluster-lifecycle
this is the second report i've seen about this so maybe we can improve the structure a little but i need to understand how.. by "beginning" do you mean ? this simply explains why draining nodes is required. if you look at the structure on the right you will see that "calling kubeadm upgrade" is meant for all control plane nodes, since it's under the parent "Upgrading control plane nodes". this means you have to go to all of them and first call "upgrade apply" or "upgrade node". then "Draining the node" is a separate section also means - do it for all control plane nodes. ! Also under "Upgrading control plane nodes" there is this text: as a user, what would you like to see as an improvement here? /triage accepted /priority awaiting-more-evidence
The upgrade procedure on control plane nodes should be executed one node at a time perhaps this text can be adjusted to the following:
Hi, 'Additional information' section at the beginning confirms that 'Draining nodes' is the very first thing to do: but that is not the case 'draining a node is a necessary step before upgrading a kubelet on a node for all node types': This is an important point and to be mentioned in the document else assumption is to drain the node before initiating upgrade action. Regards, Rajive
ok, i can see how that can be confusing. the text has a link and it sounds like a prerequisite. this can be clarified that the steps below instruct exactly when to do the drain during upgrade.
/assign /remove-priority important-more-evidence /priority backlog
Those labels are not set on the issue: <detailsIn response to : /assign /remove-priority important-more-evidence /priority backlog 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
/remove-priority awaiting-more-evidence
proposed fix is here:
Hi... This is awesome. Thank you very much..

Discussion:
### Additional information <del> - [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) before kubelet MINOR version upgrades is required. In the case of control plane nodes, they could be running CoreDNS Pods or other critical workloads. </del> <ins> - The instructions below outline when to drain each node during the upgrade process. If you are performing a **minor** version upgrade for any kubelet, you **must** first drain the node (or nodes) that you are upgrading. In the case of control plane nodes, they could be running CoreDNS Pods or other critical workloads. For more information see [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/). </ins> - All containers are restarted after upgrade, because the container spec hash value is changed. <!-- steps -->
Change:
Hello, I have recently and I have noticed that there is a slight error at step 3. Namely, the line says: when it really should be: I have tested it a few times and indeed, adding to PATH does not work, while simply adding yields the correct result (i.e. being able to invoke kubectl commands from the command prompt). I know it is a minor issue but for beginners (like myself) it could make the difference between completing the installation or not. Even though I have not tried other methods of installation, I suspect that the same step should also be corrected in section , where it also says "Add the binary in to your PATH." Best regards, Paula
/triage accepted Similar issue exists in . cf. In : !
is kind of techie vernacular (it's how I'd say it in spoken English to a colleague), but in technical docs we can be more precise. /language en
Hi, I would like to work on this issue. /assign
/sig windows

Discussion:
chmod +x kubectl mkdir -p ~/.local/bin/kubectl mv ./kubectl ~/.local/bin/kubectl <del> # and then add ~/.local/bin/kubectl to $PATH </del> <ins> # and then append (or prepend) ~/.local/bin to $PATH </ins> ``` {{< /note >}}

$($(CertUtil -hashfile .kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl.exe.sha256) ``` <del> 1. Add the binary in to your `PATH`. </del> <ins> 1. Append or prepend the kubectl binary folder to your `PATH` environment variable. </ins> 1. Test to ensure the version of `kubectl` is the same as downloaded:

$($(CertUtil -hashfile .kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl-convert.exe.sha256) ``` <del> 1. Add the binary in to your `PATH`. </del> <ins> 1. Append or prepend the kubectl binary folder to your `PATH` environment variable. </ins> 1. Verify plugin is successfully installed
Change:
This is a Bug Report Problem: The of PodSecurityAdmission is mentioned under . Which is wrong, the correct one is . Proposed Solution: Change the from to . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig auth /assign
Fixed it here:
/triage accepted

Discussion:
## Using the built-in Pod Security Admission Controller <del> {{< feature-state for_k8s_version="v1.22" state="alpha" >}} </del> <ins> {{< feature-state for_k8s_version="v1.23" state="beta" >}} </ins> The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) intends to replace the deprecated PodSecurityPolicies.
Change:
ref: , but this is also just a general feature! Blog posts by their nature go stale over time. This becomes particularly problematic when we decide to deprecate functionality in the project, as those blog posts are forever a part of the docs and forever searchable via Google. Update the blog post's templates (probably , but you may need to copy over from the Docsy theme) to include a warning for blog posts over 1 year old: Some notes: Use standard docsy warning block styles Make sure strings are in localization files so the localization teams know where to look /triage accepted /priority important-soon /area website
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ref: , but this is also just a general feature! Some notes: Make sure strings are in localization files so the localization teams know where to look /triage accepted /priority important-soon /area website 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
/area web-development
Sorry y'all, I hadn't seen this issue before I created . It turns out that there's a clean solution that doesn't involve changes to the blog template. Anyhow, this has been /cc
/close Thanks
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

Discussion:
[options_heading] other = "Options" <ins> [outdated_blog__message] other = "The Kubernetes project considers this article to be outdated because it is more than one year old. Check that the information in the page has not become incorrect since its publication." [outdated_blog__title] other = "Outdated article" </ins> [post_create_issue] other = "Create an issue"

</p> </div> </section> <ins> {{ else if and (eq .Section "blog") .Date (.Date.Before (now.AddDate -1 0 0)) -}} <section id="deprecation-warning" class="outdated-blog"> <div class="content deprecation-warning pageinfo"> <h3>{{ T "outdated_blog__title" }}</h3> <p>{{ T "outdated_blog__message" }}</p> </div> </section> </ins> {{ end }}  No newline at end of file