jiebi/CodeConvo huggingface dataset:
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: Code from the Kubernetes project sets (or previously did set) a label, This looks intended, but doesn't document that label. Proposed Solution: Document that label; as a side effect, this registers it. If it's deprecated, we should mark it as deprecated but still document it. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog
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 label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /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
Created a , Havent seen any document for it's deprecation . Please let me know if any change is needed.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Since this issue's PR is already merged. i'd like to close it
/close
Closing this issue. <detailsIn response to : /close </details

Discussion:
This label has been deprecated. Please use `kubernetes.io/os` instead. <ins> ### kube-aggregator.kubernetes.io/automanaged {#kube-aggregator-kubernetesio-automanaged} Example: `kube-aggregator.kubernetes.io/automanaged: "onstart"` Used on: APIService The `kube-apiserver` sets this label on any APIService object that the API server has created automatically. The label marks how the control plane should manage that APIService. You should not add, modify, or remove this label by yourself. {{< note >}} Automanaged APIService objects are deleted by kube-apiserver when it has no built-in or custom resource API corresponding to the API group/version of the APIService. {{< /note >}} There are two possible values: - `onstart`: The APIService should be reconciled when an API server starts up, but not otherwise. - `true`: The API server should reconcile this APIService continuously. </ins> ### kubernetes.io/hostname {#kubernetesiohostname} Example: `kubernetes.io/hostname: "ip-172-20-114-199.ec2.internal"`
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: Kubernetes previously paid attention to an annotation, . We now use instead. Even so, should document that annotation. Proposed Solution: Document that annotation; as a side effect, this registers it. I assume that we should also mark it deprecated. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog /sig scheduling
/assign
/triage accepted

Discussion:
Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) and the [Kubernetes CSI Developer Documentation](https://kubernetes-csi.github.io/docs/) for more information. <ins> ### scheduler.alpha.kubernetes.io/critical-pod (deprecated) Example: `scheduler.alpha.kubernetes.io/critical-pod: ""` Used on: Pod This annotation lets Kubernetes control plane know about a pod being a critical pod so that the descheduler will not remove this pod. {{< note >}} Starting in v1.16, this annotation was removed in favor of [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/). {{< /note >}} </ins> ## Annotations used for audit <!-- sorted by annotation -->
Change:
This is a Bug Report Problem: The Link for under is wrong. It doesn't redirect anywhere. It is redirected to the following link: instead of that, it should redirect to . contains the context of . Proposed Solution: Virtual IPs and service proxies should redirect to instead of Page to Update:
/assign /sig network /sig docs
Fixed it here:
/triage accepted

Discussion:
Kubernetes assigns this Service an IP address (sometimes called the "cluster IP"), which is used by the Service proxies <del> (see [Virtual IPs and service proxies](#virtual-ips-and-service-proxies) below). </del> <ins> (see [Virtual IP addressing mechanism](#virtual-ip-addressing-mechanism) below). </ins> The controller for the Service selector continuously scans for Pods that match its selector, and then POSTs any updates to an Endpoint object
Change:
A link reference from to has the title text whereas the current title of that page is It will be a little less confusing if the link title was adjusted to be the same as the page title.
/sig docs /language en /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind suggestion I Agree on your point. If triage accepted, i will update this reference text from to that can avoid confusion. 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 Agree on your point. If triage accepted, i will update this reference text from to that can avoid confusion.
This issue got resolved with PR .
/triage accepted

Discussion:
The Kubernetes DNS server is the only way to access `ExternalName` Services. You can find more information about `ExternalName` resolution in <del> [DNS Pods and Services](/docs/concepts/services-networking/dns-pod-service/). </del> <ins> [DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/). </ins> ## Headless Services

## {{% heading "whatsnext" %}} <ins> Learn more about the following: </ins> * Follow the [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) tutorial <del> * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) </del> <ins> * [Ingress](/docs/concepts/services-networking/ingress/) exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. * [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) </ins> For more context: <del> * Read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) * Read the [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API * Read the [API reference](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) for the Endpoints API * Read the [API reference](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) for the EndpointSlice API </del> <ins> * [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) * [API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) for the Service API * [API reference](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) for the Endpoints API * [API reference](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) for the EndpointSlice API </ins>
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: Documentation should state that spec and status downward API fields are only available as environment variables, not as files. Proposed Solution: Add text before spec.serviceAccountName stating: Then for consistency, a few lines down change: to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: Confirmed on v1.24 and v1.25 Additional Information: Error message from kubectl (1.25) apply shows which values are allowed for each type (line breaks for readability)
Thanks for the report /sig node
/triage accepted sounds reasonable, thank you
I would like to give a try on this. /assign

Discussion:
`metadata.labels['<KEY>']` : the text value of the pod's {{< glossary_tooltip text="label" term_id="label" >}} named `<KEY>` (for example, `metadata.labels['mylabel']`) <ins> The following information is available through environment variables **but not as a downwardAPI volume fieldRef**: </ins> `spec.serviceAccountName` : the name of the pod's {{< glossary_tooltip text="service account" term_id="service-account" >}}

`status.podIP` : the pod's primary IP address (usually, its IPv4 address) <del> In addition, the following information is available through a `downwardAPI` volume `fieldRef`, but **not as environment variables**: </del> <ins> The following information is available through a `downwardAPI` volume `fieldRef`, **but not as environment variables**: </ins> `metadata.labels` : all of the pod's labels, formatted as `label-key="escaped-label-value"` with one label per line
Change:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --The current documentation for suggests the use of a combination of with / to extract the contents of the field from the ConfigMap. However, has the option that allows us to extract such field without the need of parsing it through /. 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 the command to use instead. Why is this needed It provides data extraction with less steps and less risk of error if the content format changes in the future. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --N/A /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

Discussion:
* Fetch the `cluster-info` file from the API Server: ```shell <del> kubectl -n kube-public get cm cluster-info -o yaml | grep "kubeconfig:" -A11 | grep "apiVersion" -A10 | sed "s/    //" | tee cluster-info.yaml </del> <ins> kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml </ins> ``` The output is similar to this:
Change:
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. --Currently, the documentation for starting a new localization instructs only to use the language code. However, some of the languages for which the website is currently localized also have the country code, due to Docsy specificities and because the language is written differently in the places where it is spoken. Document a general guideline of when and how a language should also contain the country code attached to it when localizing Kubernetes documentation, so new locales follow the country code standard when it makes sense to do so. Why is this needed To make sure that previous decisions made by localization teams are documented in in our page. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --This is a follow-up issue to discussion on . /assign /cc
/triage accepted

Discussion:
localization's two-letter language code. For example, the two-letter code for Korean is `ko`. <ins> Some languages use a lowercase version of the country code as defined by the ISO-3166 along with their language codes. For example, the Brazilian Portuguese language code is `pt-br`. </ins> ### Fork and clone the repo First, [create your own

to find your localization's two-letter language code. For example, the two-letter code for Korean is `ko`. <ins> If the language you are starting a localization for is spoken in various places with significant differences between the variants, it might make sense to combine the lowercased ISO-3166 country code with the language two-letter code. For example, Brazilian Portuguese is localized as `pt-br`. </ins> When you start a new localization, you must localize all the [minimum required content](#minimum-required-content) before the Kubernetes project can publish your changes to the live
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: In , the word appears 3 times: But the exact name of field is actually. Proposed Solution: In , [L85-L86] [L144-L145] And optionally, we might wrap with backticks; like: through the whole doc. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign
AFAIK we use backticks only for API Resource names per the style guide. We don't need to have the backticks to wrap matchImages. I agree with the rest of the suggestion, though. /triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on /unassign
I would like to give a try on this. /assign

Discussion:
# # A match exists between an image and a matchImage when all of the below are true: # - Both contain the same number of domain parts and each part matches. <del> # - The URL path of an imageMatch must be a prefix of the target image URL path. # - If the imageMatch contains a port, then the port must match in the image as well. </del> <ins> # - The URL path of an matchImages must be a prefix of the target image URL path. # - If the matchImages contains a port, then the port must match in the image as well. </ins> # # Example values of matchImages: # - 123456789.dkr.ecr.us-east-1.amazonaws.com

* Both contain the same number of domain parts and each part matches. * The URL path of match image must be a prefix of the target image URL path. <del> * If the imageMatch contains a port, then the port must match in the image as well. </del> <ins> * If the matchImages contains a port, then the port must match in the image as well. </ins> Some example values of `matchImages` patterns are:
Change:
The right command line for usage should be: So with instead of the actual which is an unrecognized option, at least in version 1.6.0.
/retitle Wrong command in “Verify Signed Kubernetes Artifacts” task /language en
It appears that the cosign version has updated this parameter to --certificate But for compatibility with previous versions, both and can be used. So the document just uses the newer version of the command. related issue: related PR: code
Today, if you follow the instructions (and so you download 1.6.0), you get an error, so it might be useful to fix this anyway.
Perhaps, the version of needs to be indicated in the docs? For more advice.
Yes, maybe that would fix the problem as well.
I agree having the cosign version mentioned in the docs will help us to prevent such issues in the future.
/triage accepted
Page to update:
Can we also mention the note about cosign, something like this: if we are using cosign version v1.9.0+ we should use the parameter instead of the
/assign

Discussion:
cosign verify-blob "$BINARY" --signature "$BINARY".sig --certificate "$BINARY".cert ``` <ins> cosign v1.9.0 is required to be able to use the `--certificate` flag. Please use `--cert` for older versions of cosign. </ins> {{< note >}} To learn more about keyless signing, please refer to [Keyless Signatures](https://github.com/sigstore/cosign/blob/main/KEYLESS.md#keyless-signatures).
Change:
At: Very minor typo: "For example, to turning off all API versions except v1, pass --runtime-config=api/all=false,api/v1=true to the kube-apiserver." Sould be (emphasis ): For example, to turn off all API versions except v1, pass --runtime-config=api/all=false,api/v1=true to the kube-apiserver.
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

Discussion:
- `api/legacy`, representing only legacy APIs. Legacy APIs are any APIs that have been explicitly [deprecated](/docs/reference/using-api/deprecation-policy/). <del> For example, to turning off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true` </del> <ins> For example, to turn off all API versions except v1, pass `--runtime-config=api/all=false,api/v1=true` </ins> to the `kube-apiserver`. ## {{% heading "whatsnext" %}}
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: Typo in "Feature Gates" page cf. Proposed Solution: In , replace with . Page to Update: ,alpha,-.%20This%20feature%20gate%20will%20never%20graduate%20to%20stable <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
/triage accepted
Hi could you provide an update on the progress of this issue? I'm particularly interested in knowing what the current status is and if I can carry on this issue.
, I will submit a PR today .
/close
Closing this issue. <detailsIn response to : /close </details

Discussion:
This feature gate will never graduate to beta or stable. - `TopologyManagerPolicyBetaOptions`: Allow fine-tuning of topology manager policies, experimental, Beta-quality options. <del> This feature gate guards *a group* of topology manager options whose quality level is alpha. </del> <ins> This feature gate guards *a group* of topology manager options whose quality level is beta. </ins> This feature gate will never graduate to stable. - `TopologyManagerPolicyOptions`: Allow fine-tuning of topology manager policies, - `UserNamespacesStatelessPodsSupport`: Enable user namespace support for stateless Pods.
Change:
Does not describe the fields and , please add a list of all fields the spec can have, preferable with examples of use and format.
/triage accepted /kind feature
/retitle Mention and in CronJob concept page does link to which includes an explanation of these fields. /priority backlog /sig apps
/language en
Hmm, does not make sense to have these fields described by having to follow global doc link at the footer of the document. The exhaustive list of fields should be shown in the main page and for more information clearly linked to a detail page if needed. For starting users this is not clear and I can imagine for somebody not in the known you can only find this through the StackOverflow route. It also now fails to explain the possibilities of the definition as a person not aware of these fields is not informed of them as they would not know to look for them. Not a great Documentation Experience this way.
This issue is ready for a volunteer to work on it. Would anyone like to help out?
Let's add that This issue is now not about listing all the fields; for that, we already have (and that's why I changed the title of the issue)
There is a brief description of those fields in the document: are you asking for additional details? There isn't a lot more to say about them other than maybe rephrase it so it is more clear?
Rephrasing the page to be more clear would be a welcome improvement. Since this was filed, we've changed the page to link to the API reference from the right hand nav. We also have a long standing issue for , so work on this issue does not need to add a fact sheet. A brief tidy-up of the job history limit explanation would be fine to close this issue. if you're happy with the wording as-is, you are welcome to close the issue already.
/assign
Thanks see if you like the wording in the PR

Discussion:
### Jobs history limits <del> The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed Jobs should be kept. By default, they are set to 3 and 1 respectively.  Setting a limit to `0` corresponds to keeping none of the corresponding kind of Jobs after they finish. </del> <ins> The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields specify how many completed and failed Jobs should be kept. Both fields are optional. </ins> <del> For another way to clean up Jobs automatically, see [Clean up finished Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically). </del> <ins> * `.spec.successfulJobsHistoryLimit`: This field specifies the number of successful finished jobs to keep. The default value is `3`. Setting this field to `0` will not keep any successful jobs. * `.spec.failedJobsHistoryLimit`: This field specifies the number of failed finished jobs to keep. The default value is `1`. Setting this field to `0` will not keep any failed jobs. For another way to clean up Jobs automatically, see [Clean up finished Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically). </ins> ### Time zones
Change:
This is a Feature Request What would you like to be We need to update /content/ja/docs/contribute/style/content- according to the English text, because it is outdated. Why is this needed /content/ja/docs/contribute/style/content- is outdated. In the English page, a note for localication was in . It needs to be to the Japanese page. Comments /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
Related Issue : ,

Discussion:
--- title: コンテンツの構造化 content_type: concept <del> weight: 40 </del> <ins> weight: 90 </ins> --- <!-- overview -->

``` {{% note %}} <del> ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。 </del> <ins> ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。さらに、同じディレクトリ(セクション)内の各ページのweightは、重複しないようにする必要があります。これにより、特にローカライズされたコンテンツでは、コンテンツが常に正しく整列されるようになります。 </ins> {{% /note %}} ### ドキュメントのメインメニュー