jiebi/CodeConvo huggingface dataset:
Code change:
<ins> You need to have shell access to all the nodes, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. </ins>

Related discussion:
text: If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : for new contributors. You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster You need to have a Kubernetes cluster, shell access to all its nodes, and the kubectl command-line tool must be configured to communicate with your cluster /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
/kind feature /remove-priority awaiting-more-evidence
/priority backlog
This one looks like a candidate for a "good first issue" label. I think that the page should also have the shell access note, regardless of the method used (ssh, rdp, etc).
I don't think this is a good first issue. A good first issue would have a description that helped totally new contributors find out how to help, and the description for this issue at the time of writing is:
/assign
Got it. Going through the details, I see another problem here. The pre-req of having shell access to the nodes seems mostly relevant (a corner case) for the node upgrade task, for other cluster maintenance tasks, API access to node management seems enough. The problem is that the , and many other pages use the same prerequisites document (). So, adding the "get shell access to the nodes" phrase will alter all these documents where this step is not needed. I think that, for this particular task, we should not use the include prerequisite doc and rewrite the paragraph locally on the pages, as a compromise between convenience and accuracy. What do you think?
That'll work fine.
Given the need to modify two documents and the potential for content drift across releases, etc, I decided to add a new prereqs include file with the modified paragraph instead of rewriting the whole prerequisites section on both documents. Let me know what you think. Thanks
Code change:
<ins> --- title: ConfigMap id: configmap date: 2018-04-12 full_link: /ja/docs/concepts/configuration/configmap/ short_description: > 機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクトです。環境変数、コマンドライン引数、またはボリューム内の設定ファイルとして使用できます。 aka: tags: - core-object --- 機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクトです。{{< glossary_tooltip text="Pod" term_id="pod" >}}は、環境変数、コマンドライン引数、または{{< glossary_tooltip text="ボリューム" term_id="volume" >}}内の設定ファイルとしてConfigMapを使用できます。 <!--more--> ConfigMapを使用すると、環境固有の設定を{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}から分離できるため、アプリケーションを簡単に移植できるようになります。 </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
Code change:
<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-egress spec: podSelector: {} policyTypes: - Egress </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:
We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ </style> <br> <del> <br> </del> <div id="mc_embed_signup"> <form action="https://kubeweekly.us10.list-manage.com/subscribe/post?u=3885586f8f1175194017967d6&amp;id=11c1b8bcb2" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate> <div id="mc_embed_signup_scroll"> <p style="font-size: 20px">{{ T "main_kubeweekly_baseline" }}</p> <del> <br /> </del> <input type="email" value="" name="EMAIL" class="email" id="mce-EMAIL" placeholder="{{ T "input_placeholder_email_address" }}" aria-label="email" required> <!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups--> <div style="position: absolute; left: -5000px;" aria-hidden="true"><input type="text" name="b_3885586f8f1175194017967d6_11c1b8bcb2" tabindex="-1" value=""></div>

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:
max_line_length = 80 trim_trailing_whitespace = true <ins> [*.md] trim_trailing_whitespace = false </ins> [*.{css,html,js,json,sass,md,mmark,toml,yaml}] indent_style = space indent_size = 2

Related discussion:
text: This is a Bug Report Problem: is mis-configured for markdown files, and is stripping white space at the end of lines. Markdown uses these spaces for formatting in some casees. Currently, if the .editorconfig file is being used (via plugin or whatnot), then these formatting cues can be removed on save. Proposed Solution: add the following after the section in the file. dotfile to Update: .editorconfig Test environment MacOS 10.14.6 Both of: VS Code using neovim using
Good spot /kind bug /triage accepted /priority backlog
/assign
Code change:
} ``` <del> Non-resource paths include: `/api`, `/apis`, `/metrics`, `/resetMetrics`, `/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, and </del> <ins> Non-resource paths include: `/api`, `/apis`, `/metrics`, `/logs`, `/debug`, `/healthz`, `/livez`, `/openapi/v2`, `/readyz`, and </ins> `/version.` Clients require access to `/api`, `/api/*`, `/apis`, `/apis/*`, and `/version` to discover what resources and versions are present on the server. Access to other non-resource paths can be disallowed without restricting access

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: Documentation - description is not fully inline with current version. Current text: "Non-resource paths include: /api, /apis, /metrics, /resetMetrics, /logs, /debug, /healthz, /swagger-ui/, /swaggerapi/, /ui, and /version." The following non-resource don't seem to exist anymore: '/resetMetrics', '/swagger-ui' ( swagger 1.2 was deprecated and functionality seems it was already removed), '/swaggerapi'. The non-resource path '/ui' would need more checking, but it seems is part only of some tests. Proposed Solution: Description should be updated accordingly. For example, the text could be updated as: "Non-resource paths include: /api, /apis, /metrics, /logs, /debug, /healthz, /livez, /openapi/v2, /readyz and /version." Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--{ "gitVersion": "v1.18.2", "gitCommit": "" } <!--Additional Information:--
/assign
/priority important-longterm /language en
/kind bug
Code change:
Pod level control groups (cgroups) are based on the effective Pod request and limit, the same as the scheduler. <ins> {{< comment >}} This section also present under [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/) page. If you're editing this section, change both places. {{< /comment >}} </ins> ### Pod restart reasons

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:
### Metrics <ins> {{< note >}} In versions of Kubernetes before v1.20, the labels `flow_schema` and `priority_level` were inconsistently named `flowSchema` and `priorityLevel`, respectively. If you're running Kubernetes versions v1.19 and earlier, you should refer to the documentation for your version. {{< /note >}} </ins> When you enable the API Priority and Fairness feature, the kube-apiserver exports additional metrics. Monitoring these can help you determine whether your configuration is inappropriately throttling important traffic, or find

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:
main_menu: true weight: 70 content_type: concept <ins> no_list: true </ins> --- <!-- overview --> 本セクションには、Kubernetesのドキュメントのリファレンスが含まれています。 <!-- body --> ## APIリファレンス <del> * [Kubernetes API概要](/docs/reference/using-api/) - Kubernetes APIの概要です。 * [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) </del> <ins> * [標準化用語集](/ja/docs/reference/glossary) - Kubernetesの用語の包括的で標準化されたリストです。 * [Kubernetes APIリファレンス](/docs/reference/using-api/) * [Kubernetes {{< param "version" >}}の単一ページのAPIリファレンス](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [Kubernetes APIの使用](/ja/docs/reference/using-api/) - KubernetesのAPIの概要です。 * [API アクセスコントロール](/docs/reference/access-authn-authz/) - KubernetesがAPIアクセスをどのように制御するかの詳細です。 * [よく知られたラベル、アノテーション、テイント](/docs/reference/labels-annotations-taints/) </ins> <del> ## APIクライアントライブラリー </del> <ins> ## 公式にサポートされているクライアントライブラリー </ins> プログラミング言語からKubernetesのAPIを呼ぶためには、[クライアントライブラリー](/docs/reference/using-api/client-libraries/)を使うことができます。公式にサポートしているクライアントライブラリー:

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Update Why is this needed links are outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
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:
Kubelet auto-discovers these filesystems and ignores other filesystems. Kubelet does not support other configurations. <del> {{<note>}} Some kubelet garbage collection features are deprecated in favor of eviction. For a list of the deprecated features, see [kubelet garbage collection deprecation](/docs/concepts/architecture/garbage-collection/#deprecation). {{</note>}} </del> <ins> Some kubelet garbage collection features are deprecated in favor of eviction: | Existing Flag | New Flag | Rationale | | ------------- | -------- | --------- | | `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | | `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | | `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | | `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | | `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context | </ins> ### Eviction thresholds

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: In section of Node Pressure Eviction Page, a Note is referred to the deprecation section of that doesn't exist. Proposed Solution: The Note should be removed as there are no deprecated flags for kubelet garbage collection. Page to Update: /sig node
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
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /assign
Code change:
If you would like to write a concept page, see <del> [Page Content Types](/docs/home/contribute/style/page-content-types/#concept) </del> <ins> [Page Content Types](/docs/contribute/style/page-content-types/#concept) </ins> for information about the concept page types.

Related discussion:
text: This is a Bug Report Problem: The link (/docs/home/contribute/style/page-content-types/#concept) from the Concept page is not correct. Proposed Solution: Page to Update:
Thanks for spotting this. /kind bug /priority backlog /language en
Code change:
<ins> --- title: Kindを使用してKubernetesをインストールする weight: 40 content_type: concept --- <!-- overview --> Kindは、Dockerコンテナをノードとして使用して、ローカルのKubernetesクラスターを実行するためのツールです。 <!-- body --> ## インストール [Kindをインストールする](https://kind.sigs.k8s.io/docs/user/quick-start/)を参照してください。 </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
I've already translated this page, but currently, the branch is not created so I haven't created the PR yet. I'm going to create a new PR for this page after a new branch is created. The commit I've translated is here: Japanese: PRPR
masterPR
/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
Code change:
{{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}} {{< /tabs >}} <ins> ## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all} Use the following phase to update settings relevant to the kubelet after TLS bootstrap. You can use the `all` subcommand to run all `kubelet-finalize` phases. {{< tabs name="tab-kubelet-finalize" >}} {{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} {{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} {{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} {{< /tabs >}} </ins> ## kubeadm init phase addon {#cmd-phase-addon}

Related discussion:
text: This is a Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected.
Code change:
{{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}} {{< /tabs >}} <ins> ## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all} Use the following phase to update settings relevant to the kubelet after TLS bootstrap. You can use the `all` subcommand to run all `kubelet-finalize` phases. {{< tabs name="tab-kubelet-finalize" >}} {{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} {{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} {{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} {{< /tabs >}} </ins> ## kubeadm init phase addon {#cmd-phase-addon}

Related discussion:
text: So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks