jiebi/CodeConvo huggingface dataset:
Change:
flag in the `docker run` command. - The `spec.containers[].resources.limits.cpu` is converted to its millicore value and <del> multiplied by 100. The resulting value is the total amount of CPU time that a container can use every 100ms. A container cannot use more than its share of CPU time during this interval. </del> <ins> multiplied by 100. The resulting value is the total amount of CPU time in microseconds that a container can use every 100ms. A container cannot use more than its share of CPU time during this interval. </ins> {{< note >}} The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.

Discussion:
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--Reference: The spec.containers[] is converted to its millicore value and multiplied by 100. The resulting value is the total amount of CPU time that a container can use every 100ms. A container cannot use more than its share of CPU time during this interval. Problem: I'm a little confused about the description about 'millicore value'. If the is configured as ‘100m’, how long can it use every 100ms? According to the referenced text, it should be 'its millicore value', that is 100, multiplied by 100 to get a value of 10000ms. This is much longer than 100ms. Page to Update:
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-testing, kubernetes/test-infra and/or . /lifecycle stale
This is not fixed yet.
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <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
Change:
/docs/setup/learning-environment/     /docs/tasks/tools/  302! /id/docs/setup/learning-environment/     /id/docs/tasks/tools/  302! /zh-cn/docs/setup/learning-environment/     /zh-cn/docs/tasks/tools/  302! <ins> /ja/docs/setup/learning-environment/     /ja/docs/tasks/tools/  302! </ins> /hi/docs/setup/learning-environment/     /hi/docs/tasks/tools/ 302! /docs/setup/learning-environment/kind/  /docs/tasks/tools/  302 /id/docs/setup/learning-environment/kind/  /id/docs/tasks/tools/  302

Discussion:
This is a Bug Report <!--Required Information--Problem: The Japanese documentation does not apply a redirect from Getting Started Learning Environment to Tasks Tools. Without this redirection, there will be inconsistencies in information access compared to the English documentation Proposed Solution: Add a redirect from to Page to Update: Additional Information: /language ja /assign
This Issue seems to point out the differences between EN and JP. On the EN page, When we click on "Getting started" - "Learning environment" in the Left-sidebar, it will jump to docs/tasks/tools/. On the JP page, When we click on the same item in the Left-sidebar, it does not jump to docs/tasks/tools/.
It's a helpful clarification!
/triage accepted
/kind bug /remove-kind feature
I think this issues is related to bug, not feature. So could you update the description?
I have updated the description to reflect the issue as a bug.
Change:
/docs/reporting-security-issues/     /docs/reference/issues-security/security/ 301 /security/ /docs/reference/issues-security/security/ 302 <ins> /docs/concepts/security/overview/ /docs/concepts/security/ 301 </ins> /docs/roadmap/     https://github.com/kubernetes/kubernetes/milestones/ 301 /docs/samples/     /docs/tutorials/ 301

Discussion:
This is a Refactor request <!-- 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 overview page at is a bit out of date: no reference to I'm not convinced that the “Four Cs of cloud native security” model is useful for readers to learn Does not align with other CNCF documents, such as Proposed Solution: Either: remove outright migrate content from into several destinations (keep this brief but on-point) &hellip;and then redirect to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig docs /sig security /language en
If we keep the link to then we should update it to be as this is the English docs.
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 /triage accepted
Also see
/assign
I'd appreciate a (fresh) review on .
Change:
DaemonSetは、Podの作成し、そのPodが停止されることのないプロセスを持つことにおいて[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と同様です(例: webサーバー、ストレージサーバー)。 フロントエンドのようなServiceのように、どのホスト上にPodが稼働するか制御するよりも、レプリカ数をスケールアップまたはスケールダウンしたりローリングアップデートする方が重要であるような、状態をもたないServiceに対してDeploymentを使ってください。 <del> Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 </del> <ins> DaemonSetがNodeレベルの機能を提供し、他のPodがその特定のNodeで正しく動作するようにする場合、Podのコピーが全てまたは特定のホスト上で常に稼働していることが重要な場合や、他のPodの前に起動させる必要があるときにDaemonSetを使ってください。 例えば、[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)には、DaemonSetとして動作するコンポーネントが含まれていることがよくあります。DaemonSetコンポーネントは、それが動作しているNodeでクラスターネットワークが動作していることを確認します。 ## {{% heading "whatsnext" %}} * [Pod](/ja/docs/concepts/workloads/pods/)について学ぶ。 * Kubernetesの{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}コンポーネントを実行するのに便利な[静的Pod](#static-pods)について学ぶ。 * DaemonSetの使用方法を確認する * [DaemonSetでローリングアップデートを実施する](/docs/tasks/manage-daemon/update-daemon-set/) * [DaemonSetでロールバックを実行する](/docs/tasks/manage-daemon/rollback-daemon-set/) (例えば、ロールアウトが期待通りに動作しなかった場合)。 * [Node上へのPodのスケジューリング](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)の仕組みを理解する * よくDaemonSetとして実行される[デバイスプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)と[アドオン](/ja/docs/concepts/cluster-administration/addons/)について学ぶ。 * `DaemonSet`は、Kubernetes REST APIのトップレベルのリソースです。デーモンセットのAPIを理解するため{{< api-reference page="workload-resources/daemon-set-v1" >}}オブジェクトの定義を読む。 </ins>

Discussion:
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. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja
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
Change:
<ins> --- title: HostAliasesを使用してPodの/etc/hostsにエントリーを追加する content_type: concept weight: 60 min-kubernetes-server-version: 1.7 --- <!-- overview --> Podの`/etc/hosts`ファイルにエントリーを追加すると、DNSやその他の選択肢を利用できない場合に、Podレベルでホスト名の名前解決を上書きできるようになります。このようなカスタムエントリーは、PodSpecのHostAliasesフィールドに追加できます。 HostAliasesを使用せずにファイルを修正することはおすすめできません。このファイルはkubeletが管理しており、Podの作成や再起動時に上書きされる可能性があるためです。 <!-- body --> ## デフォルトのhostsファイルの内容 Nginx Podを実行すると、Pod IPが割り当てられます。 ```shell kubectl run nginx --image nginx ``` ``` pod/nginx created ``` Pod IPを確認します。 ```shell kubectl get pods --output=wide ``` ``` NAME     READY     STATUS    RESTARTS   AGE    IP           NODE nginx    1/1       Running   0          13s    10.200.0.4   worker0 ``` hostsファイルの内容は次のようになります。 ```shell kubectl exec nginx -- cat /etc/hosts ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.4	nginx ``` デフォルトでは、`hosts`ファイルには、`localhost`やPod自身のホスト名などのIPv4とIPv6のボイラープレートだけが含まれています。 ## 追加エントリーをhostAliasesに追加する デフォルトのボイラープレートに加えて、`hosts`ファイルに追加エントリーを追加できます。たとえば、`foo.local`と`bar.local`を`127.0.0.1`に、`foo.remote`と`bar.remote`を`10.1.2.3`にそれぞれ解決するためには、PodのHostAliasesを`.spec.hostAliases`以下に設定します。 {{< codenew file="service/networking/hostaliases-pod.yaml" >}} この設定を使用したPodを開始するには、次のコマンドを実行します。 ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` ``` pod/hostaliases-pod created ``` Podの詳細情報を表示して、IPv4アドレスと状態を確認します。 ```shell kubectl get pod --output=wide ``` ``` NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0 ``` `hosts`ファイルの内容は次のようになります。 ```shell kubectl logs hostaliases-pod ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.5	hostaliases-pod # Entries added by HostAliases. 127.0.0.1	foo.local	bar.local 10.1.2.3	foo.remote	bar.remote ``` ファイルの最後に追加エントリーが指定されています。 ## kubeletがhostsファイルを管理するのはなぜですか？ {#why-does-kubelet-manage-the-hosts-file} kubeletがPodの各コンテナの`hosts`ファイルを[管理する](https://github.com/kubernetes/kubernetes/issues/14633)のは、コンテナ起動後にDockerがファイルを[編集する](https://github.com/moby/moby/issues/17190)のを防ぐためです。 {{< caution >}} コンテナ内部でhostsファイルを手動で変更するのは控えてください。 hostsファイルを手動で変更すると、コンテナが終了したときに変更が失われてしまいます。 {{< /caution >}} </ins>

Discussion:
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
Change:
Below is a diagram showing how the extension points interact with the Kubernetes control plane. <del> <img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720"> </del> <!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 --> <ins> ![Extension Points and the Control Plane](/docs/concepts/extend-kubernetes/control-plane.png) </ins> ## Extension Points This diagram shows the extension points in a Kubernetes system. <del> <img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809"> </del> <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view --> <ins> ![Extension Points](/docs/concepts/extend-kubernetes/extension-points.png) </ins> 1.   Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. 2.   The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section.

Discussion:
Images which are located in are blocked by enterprise firewall, any plan to move the images to other places such as
Hi Can you identify the images that are blocked? For example, mention the URL of the documentation page that uses those images.
This page, , all images are blocked, such as
This will affect all users behind a state-level censoring filter that blocks Google Docs. /kind cleanup /triage accepted /language en
/assign
Change:
アドオンはKubernetesの機能を拡張するものです。 <del> このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。 </del> <ins> このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。この一覧は、すべてを網羅するものではありません。 </ins> <!-- body --> <del> ## ネットワークとネットワークポリシー </del> <ins> ## ネットワークとネットワークポリシー {#networking-and-network-policy} </ins> * [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 * [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。

Discussion:
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 file might be outdated. Currently in , there is no "Romana" section. It was removed by the PR . there is no section relevant to "AOS from Apstra". there is no section relevant to "Big Cloud Fabric from Big Switch Networks". there is no section relevant to "Google Compute Engine (GCE)". there is no section relevant to "Nuage Networks VCS (Virtualized Cloud Services)".Also see: Proposed Solution: Update . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ja
/triage accepted
/assign
/assign I'll also check if there are any other differences.
Change:
add nodes by setting up your own machines and either adding them manually or having them register themselves to the cluster’s apiserver. See the [Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. <del> - *Add Windows nodes to the cluster*: Kubernetes offers support for Windows worker nodes, allowing you to run workloads implemented in Windows containers. See [Windows in Kubernetes](/docs/setup/production-environment/windows/) for details. </del> - *Scale nodes*: Have a plan for expanding the capacity your cluster will eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) to help determine how many nodes you need, based on the number of pods and

Discussion:
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 mentions adding Windows nodes to your cluster as a production consideration. In fact, you might want to do this whether your cluster is running in production or not. Proposed Solution: Remove the paragraph that starts “Add Windows nodes to the cluster” from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: We missed that removal from PR Also relevant (a bit) to issue /language en /kind bug /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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The mentions adding Windows nodes to your cluster as a production consideration. In fact, you might want to do this whether your cluster is running in production or not. Remove the paragraph that starts “Add Windows nodes to the cluster” from <!--Kubernetes Version:--We missed that removal from PR Also relevant (a bit) to issue /kind bug /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
/triage accepted
/assign
Change:
`.spec.ipFamilies`, on the Service. {{< note >}} <del> The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the Service. </del> <ins> The `.spec.ipFamilies` field is conditionally mutable: you can add or remove a secondary IP address family, but you cannot change the primary IP address family of an existing Service. </ins> {{< /note >}} You can set `.spec.ipFamilies` to any of the following array values:

Discussion:
In concept docs (): but in API docs (): It's also a bit unclear what "primary IP family" means. My first thought was the primary IP family is what's used for (as opposed to which includes all IP families, not just the primary). Is that interpretation correct? If so, it might be better to avoid that terminology because there's also this text in the concept docs which makes "primary" overloaded:
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 /sig network
What i have to do in this issue?
The "conditionally mutable" part is correct; that was later and we must have missed updating some places. Yes "Primary/secondary IP family" is widely used. If you think it's confusing then the "primary/secondary field" wording should be changed, not the "primary/secondary IP family". Though really, "primary/secondary IP family" is not really that relevant in the context of individual services... the cluster as a whole has a primary service IP family, which is the family that will get assigned to single-stack services that don't explicitly request an IP family. But for services that request dual-stack, the only difference between "IPv4-primary" and "IPv6-primary" is the fact that old pre-dual-stack clients might treat them as single-stack of that family.
In the Service API docs, I think "primary IP family" is referring to the first family in the list, which may or may not be the same as the cluster's primary service IP family. Maybe we can use "first" and "second" IP families in the context of individual services:
This is feedback on documentation. I think is the page that should change. /transfer website
We might also want to reword: however, the focus of this issue is removing an inconsistency.
/assign
/triage accepted Let's make this clearer.
/unassign This issue is open to work on. Feel free to assign.
/assign
Change:
``` At the bottom of the output, there are messages indicating that the liveness <del> probes have failed, and the containers have been killed and recreated. </del> <ins> probes have failed, and the failed containers have been killed and recreated. </ins> ``` Type     Reason     Age                From               Message

Discussion:
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 documentation on readiness probes is unclear. It describes how to configure readiness for a single container, but when it comes to the restart behavior, it's not exactly clear, if just the container or the complete pod is restarted: the documentation says: but then command is used to show that the restart counter of the pod has been increased. It is not clear in the documentation, if this restart counter relates to all containers in the pod (meaning that all containers in that pod have been restarted due to failed readiness checks of a single container in that pod) or just a single container in the pod. In the example it does not matter because the pod consists of just a single container. Proposed Solution: Please clarify if a single failing container causes a restart of the whole pod or just of the affected container, and how it relates to the RESTARTS field of the output of the command. Page to Update:
/remove-kind bug This is a request to improve docs; the existing docs are unclear, not wrong. /language en /sig node /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]:
/remove-lifecycle stale
I would like to work on it.
/assign
Change:
- architecture - operation --- <!-- <del> --- </del> title: Cloud Controller Manager id: cloud-controller-manager date: 2018-04-12 full_link: /docs/concepts/architecture/cloud-controller/ short_description: > <del> Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. </del> <ins> Control plane component that integrates Kubernetes with third-party cloud providers. </ins> aka: tags: - core-object - architecture - operation <del> --- </del> --> <!-- A Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster. --> 云控制器管理器是指嵌入特定云的控制逻辑的 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}组件。 <del> 云控制器管理器允许您链接集群到云提供商的应用编程接口中， 并把和该云平台交互的组件与只和您的集群交互的组件分离开。 </del> <ins> 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 </ins> <!--more-->

Discussion:
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 reference/glossary/cloud-controller- is wrong Proposed Solution: In , In : In : and so on... Page to Update: [No webpage should be affected by the changes which this issue is suggesting.] <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language zh
/triage accepted /language zh /kind bug /assign