jiebi/CodeConvo huggingface dataset:
Code change:
## Debugging via a shell on the node {#node-shell-session} If none of these approaches work, you can find the Node on which the Pod is <del> running and create a privileged Pod running in the host namespaces. To create an interactive shell on a node using `kubectl debug`, run: </del> <ins> running and create a Pod running on the Node. To create an interactive shell on a Node using `kubectl debug`, run: </ins> ```shell kubectl debug node/mynode -it --image=ubuntu

Related discussion:
text: This is a Bug Report Problem: The following page writes: As discussed in issue , the use of "privileged" in the phrase "create a privileged Pod" is not standard usage and causes confusion because the pod is not created with the privileged flag (as ). This means that commands such as fail with and reading some process information may fail with . Proposed Solution: As far as what the actual clarification should be instead of the word "privileged", I'm not sure. I think a subject matter expert should opine on that. My guess is it should be something along the lines of: Page to Update: FYI
/assign
/sig cli /language en /triage accepted /remove-kind bug /priority backlog
/unassign PR is an attempt to resolve this issue, but the PR has been closed and this issue is not resolved yet. Please take a look discussions and suggestions in the PR before self-assign. :)
/good-first-issue /assign
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue /assign 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
The PR for this issue has already been raised earlier.
Code change:
* [gVisor](https://gvisor.dev/) intercepts syscalls from containers and runs them through a userspace kernel, written in Go, with limited access to the underlying host. <del> * [Kata Containers](https://katacontainers.io/) is an OCI compliant runtime that allows you to run </del> <ins> * [Kata Containers](https://katacontainers.io/) provide a secure container runtime that allows you to run </ins> containers in a VM. The hardware virtualization available in Kata offers an added layer of security for containers running untrusted code.

Related discussion:
text: From the docs.. As of version 2.0, Kata Containers no longer provides an OCI compliant runtime.
Hey do you want the statement to be removed or modify?
/sig security /kind bug
/language en
I'm not sure this issue is valid. For example, states: /priority awaiting-more-evidence /sig node
/triage needs-information
/cc
I have investigated and found that kata version 2 did not support OCI commands or runtime , but from we can clearly see that it has again with the 3rd version of it.
you can look into this thread.
I (still) don't think the website is wrong: Yep, true. As far as I know. Also true. That's fair too. With nothing to actually fix, I propose closing this issue. People who want to see that previous Kata Containers releases dropped OCI compliance should go and look on the Kata Containers website, per
Note that the also states that "Kata Containers 2.5.2 support the OCI Runtime Specification v1.0.0-rc5", although releases prior to 2.5.2 did not. I am a little confused by this claim, as there have been so many issues related to kata =2.0 no longer providing an OCI compliant CLI, thus breaking docker and podman compatibility, so it seemed odd for any doc to claim "Kata Containers is an OCI compliant runtime", which is why I opened this issue. (side note: for a while it looked like kata may re-add the OCI CLI commands via , but a different path to providing an OCI CLI to kata is now being pursued in ) Here's my 2c: The states: So it is possible that kata implements that spec, yet does not implement the . However, according to the docs for : ... where the word "compliance" is a link to the spec that Kata claims to implement. That is saying that for a runtime to be tested for compliance with the runtime spec, it must implement that OCI CLI. It seems reasonable that a runtime can't claim to be OCI compliant, or even compliant with that v1.0.0-rc5 runtime spec, if it does not implement the OCI Command Line Interface which is required to test that very compliance.
Code change:
* [gVisor](https://gvisor.dev/) intercepts syscalls from containers and runs them through a userspace kernel, written in Go, with limited access to the underlying host. <del> * [Kata Containers](https://katacontainers.io/) is an OCI compliant runtime that allows you to run </del> <ins> * [Kata Containers](https://katacontainers.io/) provide a secure container runtime that allows you to run </ins> containers in a VM. The hardware virtualization available in Kata offers an added layer of security for containers running untrusted code.

Related discussion:
text: I'm guessing that this is why Kata carefully worded their statement in the release notes: Note that it says kata "support the" spec, and it does not say "is compliant with" that spec. The k8s documentation, on the other hand, does state that "Kata Containers is an OCI compliant runtime." That seems incorrect based on the reasoning above.
Thanks for the additional context. If Kata Containers doesn't comply with the OCI runtime command line interface, we can fix the wording. You are welcome to provide evidence of this I would focus on whether the latest version of Kata Containers does or doesn't implement the OCI runtime command line evidence; it's also OK to furnish any other evidence that makes it clear that the Kubernetes website is not worded correctly in this respect.
I think the fact that is still open, for the sole purpose of re-enabling an OCI runtime command line interface for kata, is pretty solid evidence that even the latest version of Kata Containers does not implement the OCI runtime command line. It looks like that issue is actively being worked on, so hopefully an OCI interface will exist again at some point. It just doesn't right now.
/triage accepted /remove-priority awaiting-more-evidence /remove-triage needs-information /retitle incorrectly lists Kata Containers as OCI compliant
The actual issue is I'm working on it. I proposed a solution that restored the command lines in the runtime, but that was rejected, so I'm now working on a wrapper that converts command line to shimv2.
That is correct. Part of the problem (at least in my understanding) is that many members of the team consider that supporting the shimv2 interface is sufficient to claim OCI compatibility.
Bottom line is if Kata does not support the OCI Command line then it is just available to CRI-O and Containerd since they run as daemons and implement the Kata Shim API. Podman, buildah and other tools which exec OCI Command line tools can not and will not work with Kata until kata supports an OCI Complient Command line.
In my ideal world someone would build a C Based library for the shim V2 which could link to crun like we have done for crun-wasm and crun-krun, along with standard support in crun.
/assign
Code change:
#### Serving <del> {{< feature-state for_k8s_version="v1.20" state="alpha" >}} </del> <ins> {{< feature-state for_k8s_version="v1.22" state="beta" >}} </ins> `serving` is identical to the `ready` condition, except it does not account for terminating states. Consumers of the EndpointSlice API should check this condition if they care about pod readiness while

Related discussion:
text: This is a Bug Report <!--Required Information--The FEATURE STATE for and is mentioned under which is wrong, As per mention in the the correct Feature state for is . Proposed Solution: Update the Feature State of Serving and Terminating from to . Page to Update: <!--Additional Information:--EndpointSliceTerminatingCondition: Enables EndpointSlice and condition fields.
/assign
Fixed it here:
/language en /triage accepted
Code change:
Minimum value is 1. * `failureThreshold`: After a probe fails `failureThreshold` times in a row, Kubernetes considers that the overall check has failed: the container is _not_ ready/healthy/live. <ins> Defaults to 3. Minimum value is 1. </ins> For the case of a startup or liveness probe, if at least `failureThreshold` probes have failed, Kubernetes treats the container as unhealthy and triggers a restart for that specific container. The kubelet honors the setting of `terminationGracePeriodSeconds`

Related discussion:
text: This is a Bug Report Problem: The minimum and default values for were removed after solving . Proposed Solution: Put the information back: Page to Update:
/sig docs
/assign
/triage accepted
Code change:
content_type: task --- <del> {{< feature-state for_k8s_version="v1.20" state="alpha" >}} </del> <ins> {{< feature-state for_k8s_version="v1.24" state="beta" >}} </ins> <!-- overview -->

Related discussion:
text: This is a Bug Report <!--Required Information--Problem: The Feature state of is mentioned as under task, Which is not correct. In k8s v1.24.0 is graduated to . See the of k8s v1.24.0 and Also mention under the . Proposed Solution: Change the Feature State of from Kubernetes v1.20 [alpha] to Kubernetes v1.24 [beta]. Page to Update:
/assign
fixed it here:
As this is a bug report issue, I'm going to change the title to summarize what isn't right. /retitle Incorrect feature state data for kubelet credential provider Also: /language en /triage accepted /sig node
thanks
Code change:
[feedback_yes] other = "Tak" <ins> [final_patch_release] other = "Ostatnie wydanie poprawek" </ins> [inline_list_separator] other = "," [input_placeholder_email_address] other = "adres e-mail" <ins> [javascript_required] other = "JavaScript musi być [włączony](https://www.enable-javascript.com/pl/) na tej stronie" </ins> [latest_release] other = "Najnowsze wydanie:"

Related discussion:
text: What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language pl
/sig docs
/triage accepted
Code change:
[end_of_life] other = "Zakończenie wsparcia:" <ins> [envvars_heading] other = "Zmienne środowiska" </ins> [error_404_were_you_looking_for] other = "Czy chodziło o:" [examples_heading] other = "Przykłady" <ins> [feature_state] other = "STATUS FUNKCJONALNOŚCI:" </ins> [feedback_heading] other = "Twoja opinia"

Related discussion:
text: What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language pl
/sig docs
/triage accepted
Code change:
/docs/concepts/workloads/controllers/deployment/docs/concepts/workloads/pods/pod/     /docs/concepts/workloads/pods/pod/ 301 /docs/concepts/workloads/controllers/deployment.md     /docs/concepts/workloads/controllers/deployment/ 301 /docs/concepts/workloads/controllers/job/     /docs/concepts/workloads/controllers/jobs-run-to-completion/ 301 <del> /docs/concepts/workloads/controllers/petset/     /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/workloads/controllers/petsets/     /docs/concepts/workloads/controllers/statefulset/ 301 </del> /docs/concepts/workloads/controllers/statefulsets/     /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/workloads/controllers/statefulset.md     /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/workloads/pods/init-containers/Kubernetes/     /docs/concepts/workloads/pods/init-containers/ 301

Related discussion:
text: This is a... [ ] Feature Request [x] Bug Report Problem: There is a link missing that was supposed to be in section Differences between alpha PetSets and beta StatefulSets under it in the second point StatefulSet guards against split brain which ends with following text TODO: Link to doc about fencing. Change it and add the link that is required. Proposed Solution: Add link which is missing Page to Update:
PetSet has long been replaced by StatefuSet and StatefulSet has been GA'ed in 1.9. So we are going to remove this page to avoid further confusion.
Code change:
`Bookmark` events can be requested by `allowWatchBookmarks=true` option in watch requests, but clients shouldn't assume bookmarks are returned at any specific interval, nor may they assume the server will send any `bookmark` event. ## Retrieving large results sets in chunks <ins> {{< feature-state for_k8s_version="v1.9" state="beta" >}} </ins> On large clusters, retrieving the collection of some resource types may result in very large responses that can impact the server and client. For instance, a cluster may have tens of thousands of pods, each of which is 1-2kb of encoded JSON. Retrieving all pods across all namespaces may result in a very large response (10-20MB) and consume a large amount of server resources. Starting in Kubernetes 1.9 the server supports the ability to break a single large collection request into many smaller chunks while preserving the consistency of the total request. Each chunk can be returned sequentially which reduces both the total size of the request and allows user-oriented clients to display results incrementally to improve responsiveness.

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: describes the API List Chunking feature. However, this is a beta feature. Proposed Solution: Warn readers that this feature is not yet stable, using a Hugo shortcode. You can look up when the feature went beta from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.18 /sig api-machinery
/assign
Code change:
/docs/user-guide/kubectl-conventions/     /docs/reference/kubectl/conventions/ /docs/user-guide/kubectl-cheatsheet/     /docs/reference/kubectl/cheatsheet/ /cheatsheet /docs/reference/kubectl/cheatsheet/ 302 <del> /docs/user-guide/kubectl/kubectl_*/     /docs/reference/generated/kubectl/kubectl-commands#:splat 301 </del> <ins> /docs/user-guide/kubectl/kubectl_*     /docs/reference/generated/kubectl/kubectl-commands#:splat 301 </ins> /docs/user-guide/labels/     /docs/concepts/overview/working-with-objects/labels/ 301 /docs/user-guide/liveness/     /docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ 301 /docs/user-guide/load-balancer/     /docs/tasks/access-application-cluster/create-external-load-balancer/ 301

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 , There are some redirection rules with wildcard(``). Expectation: Netlify redirects to Reality: gives Instead, Netlify redirects (literally) to (literally) Expectation: Netlify redirects to Reality: Netlify redirects to (with trailing slash) which is not a valid anchor URL (because of the trailing slash). Proposed Solution: File to Update:  <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I would like to give this a try /assign
how can I test these redirect things after I made the changes? Do I have to make a PR to get the netlify link to test the things?
Are you working on this issue?
Ya I was trying but couldn't figure out how can I test these redirects after making the changes
Thanks, I will unassign myself. Please consider commenting before. It helps others to know about the progress of issue. /unassign
/assign
It was my bad.
I think the problem is with the link itself. Here may be is the splat. Maybe that's why it's unable to redirect. If I change the redirect to something like below without the .md it works fine And for this link , the splat is get/ and hence it redirects to This can be resolve if we remove the trailing slash from this link So, where are all these links present if we want to modify the link itself?
What a great research! I think so.
Code change:
/docs/user-guide/kubectl-conventions/     /docs/reference/kubectl/conventions/ /docs/user-guide/kubectl-cheatsheet/     /docs/reference/kubectl/cheatsheet/ /cheatsheet /docs/reference/kubectl/cheatsheet/ 302 <del> /docs/user-guide/kubectl/kubectl_*/     /docs/reference/generated/kubectl/kubectl-commands#:splat 301 </del> <ins> /docs/user-guide/kubectl/kubectl_*     /docs/reference/generated/kubectl/kubectl-commands#:splat 301 </ins> /docs/user-guide/labels/     /docs/concepts/overview/working-with-objects/labels/ 301 /docs/user-guide/liveness/     /docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ 301 /docs/user-guide/load-balancer/     /docs/tasks/access-application-cluster/create-external-load-balancer/ 301

Related discussion:
text: To do tests, you should changes on  file, a PR, and the redirection rules on the deploy preview: https://deploy-preview-xxxxx--kubernetes-io-main- And regarding your research, I suggest to make changes like these: and test on the deploy preview of the PR you will post. I did some searching and found these: content/en/blog/posts/2016-08-00-Kubernetes-Namespaces-Use-Cases- content/en/blog/posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-
I have made the PR. Let me know if I have to do some more changes or anything
Code change:
Used on: Node <del> Label that kubeadm applies on the control plane nodes that it manages. </del> <ins> A marker label to indicate that the node is used to run {{< glossary_tooltip text="control plane" term_id="control-plane" >}} components. The kubeadm tool applies this label to the control plane nodes that it manages. Other cluster management tools typically also set this taint. You can label control plane nodes with this label to make it easier to schedule Pods only onto these nodes, or to avoid running Pods on the control plane. If this label is set, [EndpointSlice controller](/docs/concepts/services-networking/topology-aware-routing/#implementation-control-plane) ignores that node while calculating Topology Aware Hints. </ins> ### node-role.kubernetes.io/control-plane {#node-role-kubernetes-io-control-plane-taint} Used on: Node <ins> Taint that kubeadm applies on control plane nodes to restrict placing pods and allow only specific pods to schedule on them. </ins> Example: `node-role.kubernetes.io/control-plane:NoSchedule` <del> Taint that kubeadm applies on control plane nodes to allow only critical workloads to schedule on them. </del> <ins> If this Taint is applied, control plane nodes allow only critical workloads to schedule on them. You can manually remove this taint with the following command on a specific node. ```shell kubectl taint nodes <node-name> node-role.kubernetes.io/control-plane:NoSchedule- ``` </ins> ### node-role.kubernetes.io/master (deprecated) {#node-role-kubernetes-io-master-taint}

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: Document the EndpointSlice controller ignores nodes with the following labels or Proposed Solution: Document labels Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/kind cleanup /language en
/assign
/sig network /triage accepted
Code change:
<ins> --- linktitle: リリースノート title: ノート type: docs description: > Kubernetesのリリースノート sitemap: priority: 0.5 --- リリースノートは、使用しているKubernetesのバージョンに合った[Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)を読むことで確認できます。 {{< skew currentVersionAddMinor 0 >}}のchangelogを見るには[GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md)を参照してください。 またリリースノートは、[relnotes.k8s.io](https://relnotes.k8s.io)上で検索してフィルタリングすることもできます。 {{< skew currentVersionAddMinor 0 >}}のフィルタリングされたリリースノートを見るには[relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0)を参照してください。 </ins>

Related discussion:
text: This is a Feature Request What would you like to be Translate into Japanese Why is this needed There is no Japanese translation for this page Comments File to translate: Original: ref. Japanese Localization document: /area localization /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:
containers: - name: mysql image: mysql <ins> env: - name: MYSQL_ROOT_PASSWORD value: "rootpasswd" </ins> volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php <del> image: php </del> <ins> image: php:7.0-apache </ins> volumeMounts: - mountPath: /var/www/html name: site-data

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: For users using K8S versions 1.8 and lower that don't have the fix contained in it may be necessary to set for the OpenStack cloud provider when installing on OpenStack clusters that expose their Cinder endpoint using paths rather than ports to avoid auto-detection errors such as: This includes for users trying out K8S on a devstack environment, and potentially other deployment tools. In this situation it is possible to resolve using: Valid values for are: With being the default. Proposed Solution: Highlight the bs-version parameter as optional (so not minimal configuration) but required in some circumstances. Page to Update: