jiebi/CodeConvo huggingface dataset:
Code 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

Related discussion:
text: --- title: Garbage Collection content_type: concept <del> weight: 70 </del> <ins> weight: 60 </ins> --- <!-- overview -->
Code 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

Related discussion:
text: title: Batch execution description: > In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired. <del> weight: 60 </del> <ins> weight: 50 </ins> --- <!-- overview -->
Code 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

Related discussion:
text: - madhusudancs title: ReplicaSet content_type: concept <del> weight: 10 </del> <ins> weight: 20 </ins> --- <!-- overview -->
Code 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

Related discussion:
text: Restarts containers that fail, replaces and reschedules containers when nodes die, kills containers that don't respond to your user-defined health check, and doesn't advertise them to clients until they are ready to serve. content_type: concept <del> weight: 20 </del> <ins> weight: 90 </ins> --- <!-- overview -->
Code 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup 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
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /assign

Related discussion:
text: - smarterclayton title: StatefulSets content_type: concept <del> weight: 40 </del> <ins> weight: 30 </ins> --- <!-- overview -->
Code 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: can be set to any value, but . If it's set to any value less than 10s the CronJob will be never scheduled. Proposed Solution: Force the value to be always greater than 10, or warn people there are non-working values Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.15.12
/kind cleanup /language en /triage accepted
Thanks
Relevant to
I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. Specifically I would add a callout, with text similar to: /good-first-issue /sig apps
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. if is set to a value less than 10 seconds then the CronJob may not be scheduled. /sig apps 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

Related discussion:
text: and if `concurrencyPolicy` is set to `Allow`, the jobs will always run at least once. <ins> {{< caution >}} If `startingDeadlineSeconds` is set to a value less than 10 seconds, the CronJob may not be scheduled. This is because the CronJob controller checks things every 10 seconds. {{< /caution >}} </ins> For every CronJob, the CronJob {{< glossary_tooltip term_id="controller" >}} checks how many schedules it missed in the duration from its last scheduled time until now. If there are more than 100 missed schedules, then it does not start the job and logs the error ````
Code 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: can be set to any value, but . If it's set to any value less than 10s the CronJob will be never scheduled. Proposed Solution: Force the value to be always greater than 10, or warn people there are non-working values Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.15.12
/kind cleanup /language en /triage accepted
Thanks
Relevant to
I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. Specifically I would add a callout, with text similar to: /good-first-issue /sig apps
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. if is set to a value less than 10 seconds then the CronJob may not be scheduled. /sig apps 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

Related discussion:
text: For instructions on creating and working with cron jobs, and for an example of CronJob manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
Code change:
This is a Bug Report <!--Required Information--Problem: In Dualstack doc updates for 1.18 , it only removes IPVS prerequisites in but not remove it in , you still can find "Kube-proxy running in mode IPVS" in the doc. Proposed Solution: remove "Kube-proxy running in mode IPVS" in Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /priority important-soon /kind bug – Can you verify the issue described is correct? If so we can tag it as a good first issue and have someone tackle it.
Hi and Thank you very much for raising this. I can indeed validate that the issue is correct and that the proposed solution is correct and would be more than happy to review a PR if someone would be happy to contribute. Thanks again
/assign
– no further action from you needed, this was a small fix. Thank you!

Related discussion:
text: * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) <del> * Kube-proxy running in mode IPVS </del> * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster {{< version-check >}}
Code change:
This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/close
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

Related discussion:
text: <ins> --- title: コンテンツの改善を提案する slug: suggest-improvements content_type: concept weight: 10 card: name: contribute weight: 20 --- <!-- overview --> Kubernetesのドキュメントに何か問題を見つけたり、新しいコンテンツに関してアイデアを思い付いたときは、issueを作ってください。必要なものは、[GitHubアカウント](https://github.com/join)とウェブブラウザーだけです。 Kubernetesのドキュメント上の新しい作業は、ほとんどの場合、GitHubのissueから始まります。Kubernetesのコントリビューターは、必要に応じてレビュー、分類、タグ付けを行います。次に、あなたやKubernetesコミュニティの他のメンバーが、そのissueを解決するための変更を加えるpull requestを開きます。 <!-- body --> ## issueを作る 既存のコンテンツに対して改善を提案したい場合や、間違いを発見した場合は、issueを作ってください。 1. ページの右側のサイドバーにある**ドキュメントのissueを作成**ボタンをクリックします。GitHubのissueページにリダイレクトし、一部のヘッダーが自動的に挿入されます。 2. 問題や改善の提案について書きます。できる限り多くの詳細情報を提供するようにしてください。 3. **Submit new issue**ボタンをクリックします。 送信後、定期的にissueを確認するか、GitHubの通知を設定してください。レビュアや他のコミュニティメンバーが、issueに対して作業を行うために、あなたに何か質問をするかもしれません。 ## 新しいコンテンツの提案 新しいコンテンツに関するアイデアがあるものの、どの場所に追加すればわからないときでも、issueを作ることができます。次のいずれかを選択して行ってください。 - コンテンツが追加されるべきだと思う既存のページを選択し、**ドキュメントのissueを作成**ボタンをクリックする。 - [GitHub](https://github.com/kubernetes/website/issues/new/)に移動し、直接issueを作る。 ## よいissueを作るには issueを作るときは、以下のことを心に留めてください。 - 明確なissueの説明を書く。不足している点、古くなっている点、誤っている点、改善が必要な点など、どの点がそうであるか明確に書く。 - issueがユーザーに与える具体的な影響を説明する。 - 合理的な作業単位になるように、特定のissueのスコープを制限する。スコープの大きな問題については、小さな複数のissueに分割する。たとえば、"Fix the security docs"(セキュリティのドキュメントを修正する)というのはスコープが大きすぎますが、"Add details to the 'Restricting network access' topic"(トピック「ネットワークアクセスの制限」に詳細情報を追加する)であれば十分に作業可能な大きさです。 - すでにあるissueを検索し、関連または同様のissueがないかどうか確認する。 - 新しいissueがほかのissueやpull requestと関係する場合は、完全なURLを参照するか、issueやpull requestの数字の前に`#`の文字を付けて参照する。例えば、`Introduced by #987654`のように書きます。 - [行動規範](/ja/community/code-of-conduct/)に従って、仲間のコントリビューターに敬意を払いましょう。たとえば、"The docs are terrible"(このドキュメントは最悪だ)のようなコメントは、役に立つ敬意のあるフィードバックではありません。 </ins>
Code change:
A page just to provide a link another page? My be you are planning more links on this page. If not this page it self can point to target page.
Hi in this there is another link reference to kubectl commands refrence , so far i am understanding is that you want to replace reference Link for kubectl command to be in this ?
To fix this, edit  so that it redirects to /good-first-issue /language en
/triage accepted
/retitle No page content for
/assign
hi could you help to review the PR? Thanks
~reviewers~ approvers for the English localization (who are mainly volunteers) pick up that task on a . I can take a look though.
/remove-good-first-issue
/assign
I the redirect () but it doesn't seem to be working on the deploy preview or locally. Any advice would be appreciated:

Related discussion:
text: /docs/reference/glossary/maintainer/    /docs/reference/glossary/approver/ 301 <ins> /docs/reference/kubectl/kubectl-cmds/     /docs/reference/generated/kubectl/kubectl-commands/ 301! </ins> /docs/reference/kubectl/kubectl/kubectl_*.md    /docs/reference/generated/kubectl/kubectl-commands#:splat 301 /docs/reference/scheduling/profiles/    /docs/reference/scheduling/config/#profiles 301
Code change:
I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /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 Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign

Related discussion:
text: Notice how the number of desired replicas is 3 according to `.spec.replicas` field. <del> 3. To see the Deployment rollout status, run `kubectl rollout status deployment.v1.apps/nginx-deployment`. </del> <ins> 3. To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. </ins> The output is similar to: ```
Code change:
I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /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 Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign

Related discussion:
text: 2. To see the rollout status, run: ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this:
Code change:
I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /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 Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign

Related discussion:
text: * The rollout gets stuck. You can verify it by checking the rollout status: ```shell <del> kubectl rollout status deployment.v1.apps/nginx-deployment </del> <ins> kubectl rollout status deployment/nginx-deployment </ins> ``` The output is similar to this: