jiebi/CodeConvo huggingface dataset:
Change:
- **rules.http.paths.pathType** (string), required <del> PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching is </del> <ins> PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching is </ins> done on a path element by element basis. A path element refers is the list of labels in the path split by the '/' separator. A request is a match for path p if every p is an element-wise prefix of p of the request path. Note that if the last element of the path is a substring of the last element in request path, it is not a match (e.g. /foo/bar matches /foo/bar/baz, but does not match /foo/barbaz). * ImplementationSpecific: Interpretation of the Path matching is up to the IngressClass. Implementations can treat this as a separate PathType or treat it identically to Prefix or Exact path types.

Discussion:
There is a display bug in section of and values are not displayed properly as is. ! I guess the list of values should be looking like this: Exact: Matches the URL path exactly. Prefix: Matches based on a URL path prefix split by '/'. Matching is done on a path element by element basis. A path element refers is the list of labels in the path split by the '/' separator. A request is a match for path p if every p is an element-wise prefix of p of the request path. Note that if the last element of the path is a substring of the last element in request path, it is not a match (e.g. /foo/bar matches /foo/bar/baz, but does not match /foo/barbaz). ImplementationSpecific: Interpretation of the Path matching is up to the IngressClass. Implementations can treat this as a separate PathType or treat it identically to Prefix or Exact path types. Implementations are required to support all path types.
/retitle Display bug in section of Ingress API referenc /sig docs /language en /triage accepted /priority backlog This could be seen as a feature request for the that generates API reference docs.
/retitle Display bug in section of Ingress API reference
/retitle Display bug in section of Ingress API referenc
/assign
Change:
`-o custom-columns=<spec>` | [カスタムカラム](#custom-columns)のコンマ区切りのリストを使用して、テーブルを表示します。 `-o custom-columns-file=<filename>` | `<filename>`ファイル内の[カスタムカラム](#custom-columns)のテンプレートを使用して、テーブルを表示します。 `-o json`     | JSON形式のAPIオブジェクトを出力します。 <del> `-o jsonpath=<template>` | [jsonpath](/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 `-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 </del> <ins> `-o jsonpath=<template>` | [jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 `-o jsonpath-file=<filename>` | `<filename>`ファイル内の[jsonpath](/ja/docs/reference/kubectl/jsonpath/)式で定義されたフィールドを表示します。 </ins> `-o name`     | リソース名のみを表示します。 `-o wide`     | 追加情報を含めて、プレーンテキスト形式で出力します。Podの場合は、Node名が含まれます。 `-o yaml`     | YAML形式のAPIオブジェクトを出力します。

Discussion:
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. --Translate reference/kubectl/jsonpath/ into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted
Change:
be reserved for the system as a whole and for Kubernetes system daemons respectively. <del> {{< note >}} Before Kubernetes version 1.20, PID resource limiting with Node-level reservations required enabling the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` to work. {{< /note >}} </del> ## Pod PID limits Kubernetes allows you to limit the number of processes running in a Pod. You

Discussion:
This is a Bug Report <!--Required Information--From k8s v1.24 the and are no longer available as a feature gate in k8s. From v1.25 there is a separate document that contains information on feature gates that have been removed i.e. . In the and feature gate link to the page which is incorrect, instead of that, it should be page. The information for both feature gates is on the Feature Gates (removed) page not on the Feature Gates page. Proposed Solution: SupportNodePidsLimit and SupportPodPidsLimit feature gates should be linked to instead of Page to Update:
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
/kind documentation /assign
For GA'ed feature or deprecated feature, if the gate is removed, we may want to remove the linking texts altogether rather than having existing text pointing to the outdate gate names.
Hi Just want to confirm it: So for this, you want to remove the whole note section for both feature gates, because both feature gates are removed. Am I understanding right?
is it seems good to you?
I meant this: move the "removed" feature to the dedicated page, if this is not done yet. The "removed" features will stay there for the sole purpose of reference. For all texts (including notes) that reference these gates, remove those references. If a feature is deprecated and removed, those texts may well become invalid. If a feature is GA'ed and removed, those texts may be still valid, but the reference to the gate should disappear.
Thanks, for your response.
and both feature gates were graduated in v1.20 and removed in v1.23. Both are present on the dedicated page i.e. . So I will remove the reference to these gates.
I will create PR for it soon.
Fixed it here:
Change:
{{< note >}} If you use a Docker credentials store, you won't see that `auth` entry but a `credsStore` entry with the name of the store as value. <ins> In that case, you can create a secret directly. See [Create a Secret by providing credentials on the command line](#create-a-secret-by-providing-credentials-on-the-command-line). </ins> {{< /note >}} ## Create a Secret based on existing credentials {#registry-secret-existing-credentials}

Discussion:
But the document doesn't say what to do in this kind of case. Creating a secret using --from-file in this case won't work; instead have to create the secret by passing the --docker-server etc arguments.
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
Change:
### 服务控制器   {#service-controller} {{< glossary_tooltip text="服务（Service）" term_id="service" >}}与受控的负载均衡器、 <del> IP 地址、网络包锅里煮、目标健康检查等云基础设施组件集成。 </del> <ins> IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 </ins> 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。 你所创建的 Service 资源会需要这些组件服务。

Discussion:
/language zh
/reopen This was incorrectly
Reopened this issue. <detailsIn response to : /reopen This was incorrectly 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
Change:
{{< blocks/kubernetes-features >}} <del> {{< blocks/case-studies >}} </del>  No newline at end of file <ins> {{< blocks/case-studies >}} </ins>

Discussion:
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 , when user clicks , ! user lands on , which is for KubeCon & CloudNativeCon North America 2021. Proposed Solution: In , [As-is] [To-be] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/triage accepted
Change:
``` For more information about the `TracingConfiguration` struct, see <del> [API server config API (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/#apiserver-k8s-io-v1beta1-TracingConfiguration). </del> <ins> [API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration). </ins> ## Stability

Discussion:
Hi, this page has a link which is 404, but I can't find this page in kubernetes website.
In this PR the page: has been removed. should point to the latest page link: /assign
/triage accepted
I could not find the description in the latest page link Is that missing?
Yes, I also checked this struct just now, it doesn't exist in the This struct was removed in version v1. Not sure about the upgrade status of this struct. /cc
There were some nits in the reference generator. We are fixing them and then regenerate the references.
TracingConfiguration is still alpha, and thus doesn't exist in the v1 version of the API.
/kind bug /language en
So do we need to create a new page containing the TracingConfiguration struct so that we can link to it? Or link to the kubernetes TracingConfiguration code line: Which one do you prefer or have a better suggestion?
I'll create a PR updating the config APIs. As for the TracingConfiguration type, it is only part of the v1alpha1 version. This means the current code is incorrect and the v1alpha1 reference needs to be back. This warrants a separate PR.
First PR created
Second PR created /assign
Change:
## GMSA limitations When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will recieve the identity of and calls from `nltest.exe /query` will work.  It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required.  The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). --> <del> ## GMSA 的局限 </del> <ins> ## GMSA 的局限  {#gmsa-limitations} </ins> 在使用 [Windows 版本的 ContainerD 运行时](/zh/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) 时，通过 GMSA 域身份标识访问受限制的网络共享资源时会出错。

Discussion:
/language zh /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 : /language zh /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
/triage accepted
/assign
Change:
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 -->

Discussion:
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
Change:
Use `activeDeadlineSeconds` on the Pod to prevent init containers from failing forever. The active deadline includes init containers. <del> However it is recommended to use `activeDeadlineSeconds` if user deploy their application </del> <ins> However it is recommended to use `activeDeadlineSeconds` only if teams deploy their application </ins> as a Job, because `activeDeadlineSeconds` has an effect even after initContainer finished. The Pod which is already running correctly would be killed by `activeDeadlineSeconds` if you set.

Discussion:
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: Proposed Solution: to to to to Page 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
Closest issue I could find related to this
Is the issue open? I would be happy to work on it. Thank you.
Do you mind testing it on your local environment. I think the documentation is correct.
/triage needs-information
/kind support
Perhaps the words "Pod" and "Job" may have been misleading. I think "Job" refers to a container that complete in a certain period. In other words, this explanation means the following. The activeDeadlineSeconds is recommended to be use for containers (Pod) that complete after a certain period. It should not be used for containers (Pod) that will run forever.
I would suggest the following. How about it? before: after:
/close Please re-open if you believe this clarification ("only if" instead of "if") is important
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
Change:
### Podセレクター <del> `.spec.selector`フィールドはPodセレクターとなります。これは[Job](/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 </del> <ins> `.spec.selector`フィールドはPodセレクターとなります。これは[Job](/ja/docs/concepts/workloads/controllers/job/)の`.spec.selector`と同じものです。 </ins> <del> Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。Podセレクターは、値を空のままにしてもデフォルト設定にならなくなりました。セレクターのデフォルト化は`kubectl apply`と互換性はありません。また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。 </del> <ins> ユーザーは`.spec.template`のラベルにマッチするPodセレクターを指定しなくてはいけません。 また、一度DaemonSetが作成されると、その`.spec.selector`は変更不可能になります。Podセレクターの変更は、意図しないPodの孤立を引き起こし、ユーザーにとってやっかいなものとなります。 </ins> `.spec.selector`は2つのフィールドからなるオブジェクトです。

Discussion:
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
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
Change:
If the `preStop` hook is still running after the grace period expires, the kubelet requests a small, one-off grace period extension of 2 seconds. <del> {{< note >}} If the `preStop` hook needs longer to complete than the default grace period allows, you must modify `terminationGracePeriodSeconds` to suit this. {{< /note >}} </del> <ins> {{% note %}} If the `preStop` hook needs longer to complete than the default grace period allows, you must modify `terminationGracePeriodSeconds` to suit this. {{% /note %}} </ins> 1. The kubelet triggers the container runtime to send a TERM signal to process 1 inside each container. <del> {{< note >}} The containers in the Pod receive the TERM signal at different times and in an arbitrary order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize. {{< /note >}} </del> <ins> There is [special ordering](#termination-with-sidecars) if the Pod has any {{< glossary_tooltip text="sidecar containers" term_id="sidecar-container" >}} defined. Otherwise, the containers in the Pod receive the TERM signal at different times and in an arbitrary order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize (or switch to using sidecar containers). </ins> 1. At the same time as the kubelet is starting graceful shutdown of the Pod, the control plane evaluates whether to remove that shutting-down Pod from EndpointSlice (and Endpoints) objects,

Discussion:
work not well. Not sure how to fix it. This issue has spreaded to the currently. <img width="550" alt="image" src=""
/triage accepted
/language en
For a likely fix, see
Change:
resources: limits: nvidia.com/gpu: 1 <del> nodeSelector: accelerator: nvidia-tesla-p100 # or nvidia-tesla-k80 etc. </del> <ins> affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: – matchExpressions: – key: beta.amd.com/gpu.family.AI # Arctic Islands GPU family operator: Exist </ins> ``` <del> This will ensure that the Pod will be scheduled to a node that has the GPU type </del> <ins> This ensures that the Pod will be scheduled to a node that has the GPU type </ins> you specified.

Discussion:
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: doesn't have our disclaimer for 3rd party content. Proposed Solution: Add a third party content disclaimer. See for an example. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /help /triage accepted
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: doesn't have our disclaimer for 3rd party content. Add a third party content disclaimer. See for an example. <!--Kubernetes Version:--/language en /help /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
Separately, it would be good if didn't include advice about installing the plugins. Instead, we can hyperlink to the vendors' own docs (where those exist).