jiebi/CodeConvo huggingface dataset:
Code change:
the configurations portable. Service accounts are different from user accounts, which are authenticated <del> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </del> <ins> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </ins> data. You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.

Related discussion:
text: No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.
Code change:
<ins> --- title: Tarefas main_menu: true weight: 50 content_type: concept --- <!-- overview --> Essa seção da documentação contém páginas que mostram como executar tarefas individuais. Essas tarefas são organizadas em uma curta sequência de etapas e passos que te auxiliam a entender conceitos básicos. Se você desejar adicionar uma tarefa, verifique como [criar um Pull Request para a documentação](/docs/contribute/new-content/open-a-pr/). </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: is giving 404 Proposed Solution: if doesn't have the pt version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
Code change:
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes. <del> * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself. </del> <ins> * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for visualizing your containers, Pods, Services and more. </ins> ## Infrastructure

Related discussion:
text: Problem: The text on is not working, on the official website of weave, it has mentioned that the service has ended so; I believe it should point to this Check the page Installing Addons  for the problem. Page to Update: Suggested Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the text Weave Cloud account link 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, on the official website of weave, it has mentioned that the service has ended so; I believe it should point to this Check the page Installing Addons  for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the text Weave Cloud account link 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
I'd change: to
/triage accepted
/sig docs
/assign
Code change:
### hostPath {#hostpath} <ins> {{< warning >}} HostPath volumes present many security risks, and it is a best practice to avoid the use of HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the required file or directory, and mounted as ReadOnly. If restricting HostPath acccess to specific directories through AdmissionPolicy, `volumeMounts` MUST be required to use `readOnly` mounts for the policy to be effective. {{< /warning >}} </ins> A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.

Related discussion:
text: This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. What would you like to be should mention field Why is this needed This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. Comments We might use a warning from as a draft and modify it accordingly. /sig auth /kind documentation
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. should mention field This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. We might use a warning from as a draft and modify it accordingly. 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
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
/remove-lifecycle stale
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
/remove-lifecycle stale
/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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .
Code change:
### hostPath {#hostpath} <ins> {{< warning >}} HostPath volumes present many security risks, and it is a best practice to avoid the use of HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the required file or directory, and mounted as ReadOnly. If restricting HostPath acccess to specific directories through AdmissionPolicy, `volumeMounts` MUST be required to use `readOnly` mounts for the policy to be effective. {{< /warning >}} </ins> A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.

Related discussion:
text: /lifecycle rotten
/remove-lifecycle rotten Still working on this?
/sig security
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-contributor-experience at . /lifecycle stale
Adding the PSS as is the future as K8S 1.21 is deprecating PSP. All Documentation for mention Read Only should also be covered in this docf from now on.
/sig storage /remove-sig auth
does this mean that readonly for hostpath is allowed and working but just not documented ?
yes, exactly
that is ownsome I was just going to rule out this solution because of the security issue. Thanks for your answer I'll test it right away.
well, I am using this manifest but I get this error
the VolumeMount on the pod spec allows a readonly setup but not on the Volume definition.
You're right and that's what I meant. Perhaps, I explained it a little vague.
well in that case I think you should close this issue as it is not an issue? the hostpath volume type does not support readonly but the container volume mount supports it and is documented here :
My point was that we can promote best practices by adding a hint to the documentation. Most of the people, don't read API specifications, they google and find a page with documentation. In this case, an advise of other options might be useful.
/remove-lifecycle stale
Would very much have appreciated if suggestion had been implemented; would have saved me a bunch of time looking for a way to mount a hostPath readonly.
/assign I can add a note in
Code change:
Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}} can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond <del> the lifetime of a pod. Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. </del> <ins> the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. For any kind of volume in a given pod, data is preserved across container restarts. </ins> At its core, a volume is just a directory, possibly with some data in it, which is accessible to the containers in a pod. How that directory comes to be, the

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: Through the progress with many contributors, the content of got a little bit unclear. ] (Most of the sentences are updated about 3 years ago.) ] Let's call the sentence Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. "the sentence A". In the paragraphs of the current version, the sentences ahead of the sentence A is not a basis or reason of the sentence A. Proposed Solution: Page to Update: /assign
/triage accepted
/sig storage
Code change:
もしあるPodの単一のInitコンテナが失敗した場合、Kubeletは成功するまで何度もそのInitコンテナを再起動します。しかし、もしそのPodの`restartPolicy`がNeverで、そのPodの起動時にInitコンテナが失敗した場合、KubernetesはそのPod全体を失敗として扱います。 <del> PodにInitコンテナを指定するためには、Podの仕様にそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトの配列として指定してください。 </del> <ins> PodにInitコンテナを指定するためには、[Podの仕様](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)に`initContainers`フィールドを`container`アイテムの配列として追加してください(アプリケーションの`containers`フィールドとそのコンテンツに似ています)。 詳細については、APIリファレンスの[Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)を参照してください。 </ins> Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。 ### 通常のコンテナとの違い {#differences-from-regular-containers}

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. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /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:
This includes any Pods created using `kubectl`, or indirectly via a replication controller. It does not include Pods created as a result of the kubelet `--manifest-url` flag, its `--config` flag, or its REST API (these are <del> not common ways to create Pods.) </del> <ins> not common ways to create Pods). The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a Secret or any other API objects. </ins> Secrets must be created before they are consumed in Pods as environment variables unless they are marked as optional. References to secrets that do

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 saw an out-of-tree product mention that static pods "can not use" ConfigMaps and Secrets. I was unaware of such a prohibition. I went looking in the k8s website. I spent a lot of time not finding any mention of such a restriction. For example: mentions static pods but not the restriction; describes ConfigMap and Secret type volumes but does not mention the restriction; the Go sources for the relevant API types do not mention the restriction (). I eventually found the restriction wrt ConfigMap mentioned in , but I think it should not appear only there. Proposed Solution: Update either or both of the first two pages I cited that currently lack the restriction. Update the API types to mention the restriction. Page to Update: Listed above. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/triage accepted
I can work on this one. Thanks. /assign
I just realized there is an additional --- and more severe --- restriction on static pods. They can not have a ! As a corollary, they are not given a by default. For example, using a static pod: ... note that there is no ! is one place where this would be relevant.
The prohibition is even broader and simpler: the definition of a static pod can not refer to any other API object. For example, PersistentVolumeClaim is another thing that a static pod's definition can not reference.
Code change:
{{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}

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:
{{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}

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
Code change:
{{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} <ins> ## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} This command can be used to generate certificate signing requests (CSRs) which can be submitted to a certificate authority (CA) for signing. {{< tabs name="tab-certs-generate-csr" >}} {{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} This command checks expiration for the certificates in the local PKI managed by kubeadm.

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.