jiebi/CodeConvo huggingface dataset:
Code change:
We also allow users to customize garbage collection policy through the following kubelet flags: 1. `minimum-container-ttl-duration`, minimum age for a finished container before it is <del> garbage collected. Default is 0 minute, which means any finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to retain </del> <ins> garbage collected. Default is 0 minute, which means every finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained </ins> per container. Default is 1. 3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. Default is -1, which means there is no global limit.

Related discussion:
text: <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: Multiple links on the page generate 404 Not Found Examples: (redirected from ) (redirected from ) Proposed Solution: fix the links Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Here is the full list of broken links on xhyve driver kvm (driver installation) xhyve (driver installation) See DRIVERS docker-env command minikube start minikube stop minikube delete full CLI docs
Code change:
We also allow users to customize garbage collection policy through the following kubelet flags: 1. `minimum-container-ttl-duration`, minimum age for a finished container before it is <del> garbage collected. Default is 0 minute, which means any finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to retain </del> <ins> garbage collected. Default is 0 minute, which means every finished container will be garbaged collected. 2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained </ins> per container. Default is 1. 3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. Default is -1, which means there is no global limit.

Related discussion:
text: I wish /docs/user-guide/horizontal-pod-autoscaling/walkthrough/ actually contained the information, or at least a link to autoscaling by custom application logic (as referred to by the first sentence in the article - . The second half of this article seems like the correct target link -
Fixed. Thanks.
Code change:
- [Pods](/docs/concepts/workloads/pods/) - [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) - [Headless Services](/docs/concepts/services-networking/service/#headless-services) <del> - [PersistentVolumes](/docs/concepts/storage/volumes/) </del> <ins> - [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) </ins> - [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) - [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) - [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget)

Related discussion:
text: This is a Bug Report Problem: page contains the following broken links: If we go through the Running ZooKeeper, A Distributed System Coordinator Introduction. If we go to click PersistentVolumes it should redirect us to PersistentVolumes Page but it shows us Volumes Page which we have to rectify here! ! Proposed Solution: Fix the broken links by Updating it to: Page to Update:
/sig docs /language en /assign
hey Can you look into this issue!!!!
/retitle Incorrect link redirection on "Running ZooKeeper" tutorial for "PersistentVolumes" /kind bug
/priority backlog (or lower) /triage accepted /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 : /priority backlog (or lower) /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
/retitle Incorrect link redirection in "Running ZooKeeper" tutorial page for "PersistentVolumes"
Thanks
But I have to work on this issue!!! I have self-assigned this issue to myself, Why someone else has raised a PR For this ??????
Code change:
{{< note >}} <!-- <del> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </del> <ins> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </ins> --> 对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL 或 CentOS 的系统，`overlay2`是首选的存储驱动程序。

Related discussion:
text: ! w sudo systemctl enable crio --now
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
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: Typo in zh/docs/setup/production-environment/container-runtimes Proposed Solution: -Page to Update: zh: (en: ) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/retitle [zh] Typo in docs/setup/production-environment/container-runtimes /kind bug /language zh
Page is a little bit lagging behind. Will fix. /assign
Code change:
This section outlines the necessary steps to use containerd as CRI runtime. <del> To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md).Return to this step once you've created a valid `config.toml` configuration file. </del> <ins> To install containerd on your system, follow the instructions on [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). Return to this step once you've created a valid `config.toml` configuration file. </ins> {{< tabs name="Finding your config.toml file" >}} {{% tab name="Linux" %}}

Related discussion:
text: This section: I would add information like here: Note: In v1.22, if the user is not setting the cgroupDriver field under KubeletConfiguration, kubeadm will default it to systemd.
this section: already links to: PRs welcome with proposed improvements. /help /sig cluster-lifecycle
If someone wants to help here, I'm not sure what steps they should follow to assist. Because of that: /remove-help
/language en
I think the suggestion is to add something about to container-runtimes pages but I don't think that fits well on that page because it only covers the container runtime side. What could be though is that there's a note/reminder to ensure they are always the same. I can work on that if we agree what's what we want here.
hmm, looks like this is already covered too.
some additional feedback in
/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]:
/assign
Code change:
## 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.

Related discussion:
text: 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
Code change:
<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-ingress spec: podSelector: {} ingress: - {} policyTypes: - Ingress </ins>

Related discussion:
text: 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
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
Code change:
</form> <h5 style="text-align: center"><a href="https://us10.campaign-archive.com/home/?u=3885586f8f1175194017967d6&id=11c1b8bcb2" aria-label="Kube Weekly" style="color: #3371E3; font-weight: 400; font-size: 20px">{{ T "main_kubeweekly_past_link" }}</a></h5> </div> <del> <br> <br> </del> <!--End mc_embed_signup--> </div> </section>

Related discussion:
text: 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 enhanced? I think "Subscribe to KubeWeekly Newsletter" section at bottom of Home page is:- too much white/grey space that can be shortend. input area where user will enter his/her email id is a little small and maybe it will be better if that gets a little enlarged. <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --!
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
/area web-development
/priority backlog
Page:
/good-first-issue The files to edit can be found in assets/scss
/remove-help /remove-good-first-issue Don't label issues as good first issues unless they are also triaged as Accepted
/assign
when we shorten this white space I feel there is no need to enlarge the input area as it aligns perfectly once shorten. !
/close
Closing this issue. <detailsIn response to : /close </details
Code change:
See [Traffic Policies](/docs/reference/networking/virtual-ips/#traffic-policies) for more details. <del> ### Trafic distribution </del> <ins> ### Traffic distribution </ins> {{< feature-state feature_gate_name="ServiceTrafficDistribution" >}}

Related discussion:
text: This seems to be a typo, shouldn't it be traffic-distribution and not trafic-distribution ?
/triage accepted /good-first-issue Yep, looks like that was a typo in the recent updates.
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 /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
/language en
/retitle Typo in "Service" concept page /kind bug
Code change:
これで、Hugoのサーバーが1313番ポートを使って開始します。お使いのブラウザにて http://localhost:1313 にアクセスしてください。リポジトリ内のソースファイルに変更を加えると、HugoがWebサイトの内容を更新してブラウザに反映します。 <ins> ## API reference pagesをビルドする `content/en/docs/reference/kubernetes-api`に配置されているAPIリファレンスページは<https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>を使ってSwagger仕様書からビルドされています。 新しいKubernetesリリースのためにリファレンスページをアップデートするには、次の手順を実行します: 1. `api-ref-generator`サブモジュールをプルする: ```bash git submodule update --init --recursive --depth 1 ``` 2. Swagger仕様書を更新する: ```bash curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json ``` 3. 新しいリリースの変更を反映するため、`api-ref-assets/config/`で`toc.yaml`と`fields.yaml`を適用する。 4. 次に、ページをビルドする: ```bash make api-reference ``` コンテナイメージからサイトを作成・サーブする事でローカルで結果をテストすることができます: ```bash make container-image make container-serve ``` APIリファレンスを見るために、ブラウザで<http://localhost:1313/docs/reference/kubernetes-api/>を開いてください。 5. 新しいコントラクトのすべての変更が設定ファイル`toc.yaml`と`fields.yaml`に反映されたら、新しく生成されたAPIリファレンスページとともにPull Requestを作成します。 </ins> ## トラブルシューティング ### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version

Related discussion:
text: This is a Feature Request What would you like to be Update README- Why is this needed has been updated after translated Comments /language ja
/triage accepted
Code change:
* `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector hoding the computed concurrency limit (based on the API server's total concurrency limit and PriorityLevelConfigurations' concurrency <del> shares), broken down by the label `priorityLevel`. </del> <ins> shares), broken down by the label `priority_level`. </ins> * `apiserver_flowcontrol_request_wait_duration_seconds` is a histogram vector of how long requests spent queued, broken down by the labels <del> `flowSchema` (indicating which one matched the request), `priorityLevel` (indicating the one to which the request was </del> <ins> `flow_schema` (indicating which one matched the request), `priority_level` (indicating the one to which the request was </ins> assigned), and `execute` (indicating whether the request started executing). {{< note >}}

Related discussion:
text: Keep the doc consistent with
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
Code change:
API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. <del> The name of a CRD object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). </del> <ins> The name of the CRD object itself must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) derived from the defined resource name and its API group; see [how to create a CRD](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions#create-a-customresourcedefinition) for more details. Further, the name of an object whose kind/resource is defined by a CRD must also be a valid DNS subdomain name. </ins> This frees you from writing your own API server to handle the custom resource, but the generic nature of the implementation means you have less flexibility than with

Related discussion:
text: 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: I wondered what are the restrictions (if any) that Kubernetes imposes on the names of objects of a kind that gets defined by a CustomResourceDefinition. I am not talking about the name of the CRD itself. I tried to find this in the documentation, and couldn't. I asked on the channel on the Kubernetes Slack, and was referred to . The text there says Since a CRD is itself an object, I thought this was clearly talking about the name of the CRD itself (I temporarily forgot that I know that the name of the CRD itself is constrained to be ). But I was assured that this text is trying to talk about the objects whose kind is defined by the CRD. Proposed Solution: Update the cited doc to be clearer. Page to Update:
/sig docs /language en
/triage accepted /wg api-expression Since a CRD is itself an object, I thought this was clearly talking about the name of the CRD itself Yes, that's right. Both I and confirm this; I'm an emeritus tech lead for SIG Docs, and is a current tech lead. (sic) Would be good to add that detail to the page.
Code change:
The latter selects all resources with key equal to `tier` and value distinct from `frontend`, and all resources with no labels with the `tier` key. One could filter for resources in `production` excluding `frontend` using the comma operator: `environment=production,tier!=frontend` <ins> One usage scenario for equality-based label requirement is for Pods to specify node selection criteria. For example, the sample Pod below selects nodes with the label "`accelerator=nvidia-tesla-p100`". ```yaml apiVersion: v1 kind: Pod metadata: name: cuda-test spec: containers: - name: cuda-test image: "k8s.gcr.io/cuda-vector-add:v0.1" resources: limits: nvidia.com/gpu: 1 nodeSelector: accelerator: nvidia-tesla-p100 ``` </ins> ### _Set-based_ requirement

Related discussion:
text: <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [ ] Bug Report [x] Documentation request Problem: Can we use equality-based requirement selectors like this in yaml/json files: Proposed Solution: Clearly mention if this is possible and if so include a small example. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign
Code change:
You can specify init containers in the Pod specification alongside the `containers` array (which describes app containers). <ins> In Kubernetes, a [sidecar container](/docs/concepts/workloads/pods/sidecar-containers/) is a container that starts before the main application container and _continues to run_. This document is about init containers: containers that run to completion during Pod initialization. </ins> <!-- body -->

Related discussion:
text: restartPolicy under initContainers is not allowing to create Jobs specified into the below documents Error Message: Job in version "v1" cannot be handled as a Job: strict decoding error: unknown field "[0].restartPolicy" Document Link:
Hi I believe the error message you are getting is because you might have used feild under the section. But it is not allowed under the . /language en
Page related to the issue: /sig docs /sig node
Hi , Below is the Job configuration:
Could you please provide the code block with proper indentation?
updated above section
The indentation should be corrected as below
/kind bug
mentions a feature gate, but doesn't make it explicitly clear that you need to enable it. The feature gate is named . The fix I recommend: add a brand new page edit to direct readers to that new page /remove-kind bug I don't think there is anything actually incorrect. /triage accepted /retitle Unclear documentation about sidecar containers
Is anybody working to fix this issue? If no, i can take it.
/assign
Feel free to involve me, if you need any help.
Sure, Thank you.
PR raised to fix the issue .
Also see
To learn more, you can read (but not plagiarize)
Hi, I also having this problem I tried to add restartPolicy as to under containers and init containers, but I get the same error. I do not got any errors for the restartPolicy, but and are gave the error mentioned at the top. Im using Minikube, and my CC: Your suggestions highly appriciatable
Looks like you are using 1.27, but this feature was in 1.28.
Thanks I updated my k8s Even though I can not use and in both places. ( and I put this marker in the above comment). It says,
Code change:
{{< /note >}} Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working. <del> To enable bash autocompletion in current session of shell, source the ~/.bashrc file: </del> <ins> To enable bash autocompletion in current session of shell, run `exec bash`: </ins> ```bash <del> source ~/.bashrc </del> <ins> exec bash </ins> ```

Related discussion:
text: 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 somebody configures shell completion for , the instructions explain how to turn that on for your current session. However, that advice only works if the reader picked the approach in the “User” tab. If someone picked the “System” tab, the advice does not help them update their current session. Proposed Solution: Change that page to advise the user to run Some other change that also helps the user, regardless of which approach they took. Page to Update: Additional Information: Prompted by /language en /priority backlog
/triage accepted
/assign
Code change:
{ type: 0, name: 'ASM Technologies Limited', <del> logo: 'asmtech', </del> <ins> logo: 'asm', </ins> link: 'http://www.asmtech.com/', <del> blurb: 'http://www.asmtech.com/audience-channels/software_publisher/' </del> <ins> blurb: 'Our technology supply chain portfolio enables your software products to be accessible, viable and available more effectively.' </ins> }, { type: 1,

Related discussion:
text: <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [X] Bug Report Problem: The link "build-tools/" doesn't work anymore and returns 404. Proposed Solution: Fix the link Page to Update:
Fixed. Thanks!