jiebi/CodeConvo huggingface dataset:
Change:
<del> #!/bin/bash #!/usr/bin/env bash # This script reproduces what the kubelet does # to calculate memory.available relative to root cgroup. # current memory usage memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}') memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024)) memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}') memory_working_set=${memory_usage_in_bytes} if [ "$memory_working_set" -lt "$memory_total_inactive_file" ]; then memory_working_set=0 else memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file)) fi memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set)) memory_available_in_kb=$((memory_available_in_bytes / 1024)) memory_available_in_mb=$((memory_available_in_kb / 1024)) echo "memory.capacity_in_bytes $memory_capacity_in_bytes" echo "memory.usage_in_bytes $memory_usage_in_bytes" echo "memory.total_inactive_file $memory_total_inactive_file" echo "memory.working_set $memory_working_set" echo "memory.available_in_bytes $memory_available_in_bytes" echo "memory.available_in_kb $memory_available_in_kb" echo "memory.available_in_mb $memory_available_in_mb" </del>

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: There is a broken link to script in tasks/administer-cluster/out-of- file. At 44 line: Proposed Solution: Move the script file to examples directory. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign
Change:
<ins> --- title: ラベル id: label date: 2018-04-12 full_link: /docs/concepts/overview/working-with-objects/labels short_description: > ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。 aka: tags: - fundamental --- ユーザーにとって意味があり関連性のある識別属性を、オブジェクトにタグ付けするものです。 <!--more--> ラベルは、{{< glossary_tooltip text="Pod" term_id="pod" >}}などのオブジェクトに付与されるキーと値のペアです。オブジェクトのサブセットを組織化したり選択したりするために使われます。 </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:
### 安定したストレージ <del> Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1GiBのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。 </del> <ins> StatefulSetで定義された各VolumeClaimTemplateに対して、各Podは1つのPersistentVolumeClaimを受け取ります。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1GiBのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。 </ins> 注意点として、PodのPersistentVolume Claimと関連したPersistentVolumeは、PodやStatefulSetが削除されたときに削除されません。 削除する場合は手動で行わなければなりません。

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. --I think in Japanese StatefulSet page is a little confusing. It says that one Persistent Volueme (PV) is created per VolumeClaimTemplate. So, I imagined that if I defined a VolumeClaimTemplate and replicas=3, 1 PV would be created. However, in reality, 1 PV is assigned to each pod, resulting in 3 PVs being created. And in , it doesn't mention Persistent Volume. I think it is better that Stable Storage section in Japanese is updated. Why is this needed Stable Storage section in Japanese is a little confusing. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/language ja
/kind bug
PV and PVC are 1:1 mapping with pods. so Japanese explanation has to be updated
Thanks If you are interested, would you like to work on this issue? If it’s difficult to work, please comment with . /area localization /triage accepted
Thanks, I want to try to work on this issue! /assign
Change:
* `template` 字段包含以下子字段： * Pod 被使用 `.metadata.labels` 字段打上 `app: nginx` 标签。 * Pod 模板规约（即 `.template.spec` 字段）指示 Pods 运行一个 `nginx` 容器， <del> 该容器运行版本为 1.14.2 的 `nginx` [Docker Hub](https://hub.docker.com/)镜像。 </del> <ins> 该容器运行版本为 1.14.2 的 `nginx` [Docker Hub](https://hub.docker.com/) 镜像。 </ins> * 创建一个容器并使用 `.spec.template.spec.containers[0].name` 字段将其命名为 `nginx`。 <!--

Discussion:
There are some bugs: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" "image updated to 1.9.1" should be changed to "image updated to 1.16.1" The content of this article has many "", it could be changed to "deployment". For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
/language zh
/triage accepted
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
looks like docs is already updated to nginx:1.16.1. Do you mind closing this issue?
There should still be a few places left unfinished.
Could you please edit the issue which needs to be still updated?
Bug1: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" Bug2: ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" Bug3: "image updated to 1.9.1" should be changed to "image updated to 1.16.1" Bug4: The content of this article has many "", it could be changed to "deployment".

For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
Thanks for clarifying. /assign
/retitle [zh] Localization bugs / work required for Deployment concept
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
Change:
Techniques for spreading traffic across failure domains differs between cloud providers. Please check the documentation of the relevant [Ingress controller](/docs/concepts/services-networking/ingress-controllers) for details. <del> for details on deploying Ingress in a federated cluster. </del> ## Alternatives

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: Line 496: the line should be removed completely Techniques for spreading traffic across failure domains differs between cloud providers. Please check the documentation of the relevant for details. for details on deploying Ingress in a federated cluster. Proposed Solution: Line 496: the line should be removed completely Techniques for spreading traffic across failure domains differs between cloud providers. Please check the documentation of the relevant for details. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/kind bug /language en /priority backlog
Change:
## {{% heading "whatsnext" %}} <del> [Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format) </del> <ins> [Cron expression format](https://en.wikipedia.org/wiki/Cron) </ins> documents the format of CronJob `schedule` fields. For instructions on creating and working with cron jobs, and for an example of CronJob

Discussion:
Problem: The 5 fields of the cronJob schedule format are not described on the page - there is only a link to some external documetation (). This documentation however is for a 6 field format which include an extra seconds field at the start. Also the use of in the examples isn't required because `` already means every minute. Proposed Solution: Linking to a page which describes the 5 field version of the cron format e.g. the Wikipedia page: Page to Update:
/kind bug /priority important-longterm /language en
Change:
use the volume. The scheduler then schedules Pods onto nodes where the volume is available after the volume has been created. <del> For [CSI ephemeral volumes](/docs/concepts/storage/volumes/#csi), </del> <ins> For [CSI ephemeral volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes), </ins> scheduling always happens without considering storage capacity. This is based on the assumption that this volume type is only used by special CSI drivers which are local to a node and do not need

Discussion:
Problem: The text on is not working, it should point to this Check the page for the problem. Page to Update: Proposed Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text CSI ephemeral volumes to and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on is not working, it should point to this Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text CSI ephemeral volumes to and not to this . /assign /language en 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
/sig storage
/kind documentation
Change:
[release_date_format] other = "2006-01-02" <ins> # Deprecated. Planned for removal in a future release. # Use [release_full_details_initial_text] instead. [release_complete] other = "완료" # Replace [release_complete] with [release_full_details_initial_text] [release_full_details_initial_text] other = "전체" [release_schedule] other = "일정" [release_changelog] other = "변경 이력" </ins> [seealso_heading] other = "더 보기"

Discussion:
What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language ko
/triage accepted Thanks !
/assign
Change:
[headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the <del> `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.ClusterIP` is set to </del> <ins> `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.clusterIP` is set to </ins> `None`. {{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}}

Discussion:
page is plenty of wrong references to the non defined ` instead.
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /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
/kind bug
/assign
Thanks for solving this so so quick (you are the best ;-)
Change:
The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following: ``` <del> # install dependencies yarn </del> # pull in the Docsy submodule git submodule update --init --recursive --depth 1 ```

Discussion:
This is a Bug Report As discussed in the SIG-Docs meeting, the current steps for building doc website in README is incomplete in the following point of views. It requires yarn on top of npm, but is missing and package- is there. did not work for me but I need further investigation on it. The build step is going to be equal in containerized and local in , but yarn installation or npm ci is currently missing in . <!--Required Information--Proposed Solution: and remove yarn from the dependency the npm command inside of the container Page to Update: N/A
Here's my cat picture after the sig-docs meeting lol !
AIUI, the live website build (within Netlify) relies on , and does not use Yarn.
/area web-development
Could you have a quick look if npm ci in local works just fine?
Yes, I believe so.
worked in my local environment
/kind bug /priority important-longterm
/sig contributor-experience I suppose
Change:
<del> You need to either have a dynamic PersistentVolume provisioner with a default </del> <ins> You need to either have a [dynamic PersistentVolume provisioner](/docs/concepts/storage/dynamic-provisioning/) with a default </ins> [StorageClass](/docs/concepts/storage/storage-classes/), or [statically provision PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning) yourself to satisfy the [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims)

Discussion:
Please provide links on the 'Before you begin' section, teaching how to 'have dynamic PersistentVolume provisioner with a default StorageClass'. I'm quite new to K8s and am not sure how to verify if I have the former half of this sentence, and the latter end of it (static provisioning) looks less automated / more difficult.
Seems like it could just link here:
If anyone does work on this, it's easier to review PRs that only touch a single localization.
/language en /triage accepted /priority backlog
do we have any section on dynamic PersistentVolume provisioner with a default StorageClass ?
Let's open that question up - anyone who wants to answer it is welcome to.
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]:
Change:
--> <!-- <del> Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. </del> <ins> The API server is a component of the Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane. </ins> --> <del> 主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。 </del> <ins> API 服务器是 Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}}的组件， 该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。 </ins> <!--more--> <!-- <del> It is designed to scale horizontally - that is, it scales by deploying more instances. See [Building High-Availability Clusters](/docs/admin/high-availability/). </del> <ins> The main implementation of a Kubernetes API server is [kube-apiserver](/docs/reference/generated/kube-apiserver/). kube-apiserver is designed to scale horizontally&mdash;that is, it scales by deploying more instances. You can run several instances of kube-apiserver and balance traffic between those instances. </ins> --> <del> kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之，通过部署多个实例可以实现扩缩。 参见[构造高可用集群](/docs/admin/high-availability/)。 </del> <ins> Kubernetes API 服务器的主要实现是 [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。 kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。 </ins>

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: when I finished the translation of docs/reference/using-api/health-, I found a broken link when clicked the "API ":  Proposed Solution: fix it in
/language zh /assign /kind bug
/triage accepted
Change:
Untuk mengunduh versi spesifik, ganti bagian `curl -LS https://dl.k8s.io/release/stable.txt` dengan versi yang diinginkan. <del> Misalnya, untuk mengunduh versi {{< param "fullversion" >}} di Linux, ketik: </del> <ins> Misalnya, untuk mengunduh versi {{< skew currentPatchVersion >}} di Linux, ketik: </ins> ``` <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl </ins> ``` 2. Jadikan program `kubectl` dapat dieksekusi.

Discussion:
Problem: Based on , I have created this issue/task to help update the [id] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/id" /home/rdlugyhe/kubernetes/k8s-website/content/id/docs/tasks/tools/install- 34: Misalnya, untuk mengunduh versi {{< param "fullversion" }} di Linux, ketik: 37: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 114: Misalnya, untuk mengunduh versi {{< param "fullversion" }} pada macOS, ketik: 117: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 179: 1. Unduh versi terbarunya {{< param "fullversion" }} dari tautan ini /sig docs /sig localization /language id cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: Page to Update: /home/rdlugyhe/kubernetes/k8s-website/content/id/docs/concepts/extend-kubernetes/compute-storage-net/network- /sig localization /language id cc: 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 /area localization /priority backlog
Change:
ARCH="amd64" mkdir -p /opt/bin cd /opt/bin <del> curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} </del> <ins> curl -L --remote-name-all https://dl.k8s.io/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} </ins> chmod +x {kubeadm,kubelet,kubectl} curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service

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: There are still references to instead of is the correct advertised download host and will eventually move to be fastly shielding a fully community-owned bucket ref: Proposed Solution: Replace with Also replace any references with using if applicable. Page to Update: Assorted e.g. , <!--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
hi Not a problem, didn't see anyone assigned to this issue. I am unassigning myself and assigning it to you. /unassign
/assign
Hi, I found a small issue with your proposed changes regarding one of the URLs, which is mentioned twice in the file. While returns as expected, I am getting an nginx-rendered HTML page saying for the new command () instead. As I understand, it happens due to the redirect configured on the new web server. Thus, works fine for me (it returns as expected).
i see Let me update it, thanks your work
Just done, please review all of PRs
Thanks!
And yes: These will need to follow redirects, in the future the tentative plan is it will redirect to a CDN in front of a different bucket created in a fully project / SIG-K8s-Infra controlled GCP or AWS account. I would recommend for downloading with curl more generally, even in docs / usage for other hosts.