jiebi/CodeConvo huggingface dataset:
Change:
in this sentence the AWS and OpenStack positions at the end should be swapped, or perhaps clarified. OpenStack was removed in 1.25 (gone in 1.26) and AWS was removed in 1.26 (gone in 1.27).
Blog related to the issue: /language en
/area blog
/triage accepted

Discussion:
and **will require changes** for users who were previously using the in-tree provider integrations. The legacy integrations offered compatibility with Azure, AWS, GCE, OpenStack, and vSphere; however for AWS and OpenStack the <del> compiled-in integrations were removed in Kubernetes versions 1.26 and 1.27, </del> <ins> compiled-in integrations were removed in Kubernetes versions 1.27 and 1.26, </ins> respectively. ## What has changed?
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: The example Ingress contains rewrite annotation: But with new ingress 0.22 + capture groups must be explicit, see As result this example rewrites all paths with / - it does work for simple example, but it breaks any more complex web service! So if some body uses it as template and edits it for his own use case, can get into trouble, which are bit tricky to detect. Proposed Solution: Just delete rewrite-target annotation and ingress will work as expect by default. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
issue page: /language en
Starting in Version 0.22.0, ingress definitions using the annotation are not backwards compatible with previous versions. In Version 0.22.0 and beyond, any substrings within the request URI that need to be passed to the rewritten path must explicitly be defined in a capture group. As this is simple ingress example so no rewrite example is needed
/triage accepted
/assign

Discussion:
kind: Ingress metadata: name: example-ingress <del> annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 </del> spec: ingressClassName: nginx rules:
Change:
After running the kubectl apply command at , "kubectl get all" shows it is having "ImagePullBackOff" error When I do a describe it says the image is too old and need to be updated According to this link , the image was created back in 2016. Can we either update all the sample images to use manifest version 2 or find another image that works out of the box?
Related issue:
We shoudl fix this i think. sftim Any idea how we could resolve to help with tutorial working again?
Sample yaml reported in the issue: /language en
It seems that the image may have been removed by Google. We can either update the sample with image's new location (will need some searching), similar to what we’ve done for other tutorials (example ), or find a suitable alternative image to use.
I'd love to help out if appropriate, it appears to be a good first issue but I am not sure.
Would be good to fix this issue with the tutorial. /priority backlog /triage accepted
/kind bug

Discussion:
response to a successful request is a hello message: ```none <del> Hello Kubernetes! </del> <ins> Hello, world! Version: 2.0.0 Hostname: hello-world-cdd4458f4-m47c8 </ins> ``` ## Using a service configuration file

spec: containers: - name: hello-world <del> image: gcr.io/google-samples/node-hello:1.0 </del> <ins> image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0 </ins> ports: - containerPort: 8080 protocol: TCP
Change:
Hi k8s community, This issue refers to the documentation page, specifically to the "Services" chapter (link: ). The description of the field is missing relevant clarifications; here below what we have nowadays:: Allocates IPv4 and IPv6 cluster IPs for the Service. from both IPv4 and IPv6 address ranges. Selects the array. The current text for ) (note I used bold letters to remark the text) below), falling back to single-stack behavior if dual-stack not enabled/supported. from both IPv4 and IPv6 address ranges when dual-stack enabled, failing to create the Service API object if dual-stack not enabled/supported Selects the array.
Page reported in issue: /language en
/sig network
/triage accepted

Discussion:
* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range. <del> * `PreferDualStack`: * Allocates IPv4 and IPv6 cluster IPs for the Service. * `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges. </del> <ins> * `PreferDualStack`: Allocates both IPv4 and IPv6 cluster IPs for the Service when dual-stack is enabled. If dual-stack is not enabled or supported, it falls back to single-stack behavior. * `RequireDualStack`: Allocates Service `.spec.clusterIPs` from both IPv4 and IPv6 address ranges when dual-stack is enabled. If dual-stack is not enabled or supported, the Service API object creation fails. </ins> * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array.
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. --I think in Japanese StatefulSet page is a little confusing. It says that one Persistent Volueme (PV) is created per VolumeClaimTemplate. So, I imagined that if I defined a VolumeClaimTemplate and replicas=3, 1 PV would be created. However, in reality, 1 PV is assigned to each pod, resulting in 3 PVs being created. And in , it doesn't mention Persistent Volume. I think it is better that Stable Storage section in Japanese is updated. Why is this needed Stable Storage section in Japanese is a little confusing. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/language ja
/kind bug
PV and PVC are 1:1 mapping with pods. so Japanese explanation has to be updated
Thanks If you are interested, would you like to work on this issue? If it’s difficult to work, please comment with . /area localization /triage accepted
Thanks, I want to try to work on this issue! /assign

Discussion:
### 安定したストレージ <del> Kubernetesは各VolumeClaimTemplateに対して、1つの[PersistentVolume](/docs/concepts/storage/persistent-volumes/)を作成します。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1GiBのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。 </del> <ins> StatefulSetで定義された各VolumeClaimTemplateに対して、各Podは1つのPersistentVolumeClaimを受け取ります。上記のnginxの例において、各Podは`my-storage-class`というStorageClassをもち、1GiBのストレージ容量を持った単一のPersistentVolumeを受け取ります。もしStorageClassが指定されていない場合、デフォルトのStorageClassが使用されます。PodがNode上にスケジュール(もしくは再スケジュール)されたとき、その`volumeMounts`はPersistentVolume Claimに関連したPersistentVolumeをマウントします。 </ins> 注意点として、PodのPersistentVolume Claimと関連したPersistentVolumeは、PodやStatefulSetが削除されたときに削除されません。 削除する場合は手動で行わなければなりません。
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: mentions a feature gate; however, Kubernetes v1.23 onwards don't have such a feature gate. This is in connection with a label, . Proposed Solution: Drop the mention of the feature gate. Reword the description of that label accordingly. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /kind bug /priority backlog
/triage accepted
I would to like to work on this issue. /assign
/sig docs
The issue is fixed .

Discussion:
Used on: Node <del> Kubernetes automatically enables the `ServiceNodeExclusion` feature gate on the clusters it creates. With this feature gate enabled on a cluster, you can add labels to particular worker nodes to exclude them from the list of backend servers. </del> <ins> You can add labels to particular worker nodes to exclude them from the list of backend servers used by external load balancers. </ins> The following command can be used to exclude a worker node from the list of backend servers in a backend set:
Change:
Hi Team As per the documentation link: Kube api-server is supposed to validate the keys for secret type: However, I have observed that secrets are still being created if the valid keys are not in the secret manifest. apiVersion: v1 kind: Secret metadata: name: secret-basic-auth type: stringData: username: admin # required field for
Thanks for mentioning this. What's not right about the documentation, in your opinion, /language en
As per documentation, for the secret type: , they keys (username, password) are validated during secret creation. However, I am able to generate this secret of type without mentioning password key in the manifest. Is the documentation correct? If yes, then validation is missing?
It sounds like you're saying that specifically is wrong. As well as removing that text, we make it clear that “must” means ”you are expected to ensure this” and not “your cluster enforces this“. /triage accepted If you want the cluster to enforce that those keys are set, you could make a feature request As an aside: would be nice to document some ValidatingAdmissionPolicies that do enforce this rule.
/assign I will create a PR for fixing this.
Fixed in /close
Closing this issue. <detailsIn response to : Fixed in /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

Discussion:
However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other people to understand the purpose of your Secret, and sets a convention for what key names to expect. <del> The Kubernetes API verifies that the required keys are set for a Secret of this type. </del> ### SSH authentication Secrets
Change:
Note that this issue is for Japanese Speaker 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: Japanese Localization document: /area localization /language ja /good-first-issue
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 : Note that this issue is for Japanese Speaker Original: /language ja /good-first-issue 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
/triage accepted

Discussion:
<ins> --- title: CRI-O id: cri-o date: 2019-05-14 full_link: https://cri-o.io/#what-is-cri-o short_description: > Kubernetesに特化した軽量コンテナランタイム aka: tags: - tool --- Kubernetes CRIと一緒にOCIコンテナランタイムを使うためのツールです。 <!--more--> CRI-OはOpen Container Initiative (OCI) [runtime spec](https://www.github.com/opencontainers/runtime-spec)と互換性がある{{< glossary_tooltip text="コンテナ" term_id="container" >}}ランタイムを使用できるようにするための{{< glossary_tooltip term_id="cri" >}}の実装の１つです。 CRI-Oのデプロイによって、Kubernetesは任意のOCI準拠のランタイムを、{{< glossary_tooltip text="Pod" term_id="pod" >}}を実行するためのコンテナランタイムとして利用することと、リモートレジストリからOCIコンテナイメージを取得することができるようになります。 </ins>
Change:
This is a Bug Report Problem: An explanation in the Pod phase section is misleading. A pod doesn't have a state until it is configured not to be restarted. If the is not set, the pod will still be in the state. Proposed Solution: All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system, and will not be restarted. Page to Update: Kubernetes Version: v1.30.1 I'll be happy to work on it if it's accepted.
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
/language en /sig docs
/sig node
so long as you're confident your understanding is correct, you don't need anyone to tell you it's OK to start work. Kubernetes is open source.
That’s true, thanks. /assign

Discussion:
`Pending`   | The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run. This includes time a Pod spends waiting to be scheduled as well as the time spent downloading container images over the network. `Running`   | The Pod has been bound to a node, and all of the containers have been created. At least one container is still running, or is in the process of starting or restarting. `Succeeded` | All containers in the Pod have terminated in success, and will not be restarted. <del> `Failed`    | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system. </del> <ins> `Failed`    | All containers in the Pod have terminated, and at least one container has terminated in failure. That is, the container either exited with non-zero status or was terminated by the system, and is not set for automatic restarting. </ins> `Unknown`   | For some reason the state of the Pod could not be obtained. This phase typically occurs due to an error in communicating with the node where the Pod should be running. {{< note >}}

* For detailed information about Pod and container status in the API, see the API reference documentation covering <del> [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod. </del>  No newline at end of file <ins> [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod. </ins>
Change:
This is a Feature Request <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--What would you like to be The blog submission guidelines currently do not reflect the new format required for front matter, particularly the inclusion of author metadata. This discrepancy could lead to confusion and incorrect submissions from contributors who follow the outdated format. The existing guidelines need to be updated to reflect this change. Proposed Solution: Update the example front matter on the to demonstrate the correct format for including author metadata. Ensure that any related content, such as instructions or explanations surrounding the addition of author information, is also updated to reflect the new requirement. Reference of a published blog following the new format: Example of new format: Page to Update: Page URL: source: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /sig docs /area blog
/triage accepted /help
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 : /triage accepted /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
/priority backlog
/assign

Discussion:
title: "Your Title Here" date: YYYY-MM-DD slug: text-for-URL-link-here-no-spaces <ins> author: > Author-1 (Affiliation), Author-2 (Affiliation), Author-3 (Affiliation) </ins> --- ```

- Keep the blog content the same. If there are changes, they should be made to the original article first, and then to the mirrored article. - The mirrored blog should have a `canonicalUrl`, that is, essentially the url of the original blog after it has been published. <del> - [Kubernetes contributor blogs](https://kubernetes.dev/blog) have their authors mentioned in the YAML header, while the Kubernetes blog posts mention authors in the blog content itself. This should be changed when mirroring the content. </del> <ins> - Same as [Kubernetes contributor blogs](https://kubernetes.dev/blog), Kubernetes blog posts also mention authors in the YAML header as per the new guidelines. This should be ensured. </ins> - Publication dates stay the same as the original blog. All of the other guidelines and expectations detailed above apply as well.
Change:
Ref :- /assign /sig api-machinary
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Ref :- /sig api-machinary 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
/sig api-machinery
What's SVM Contributors might need more of a clue about what work needs doing.
It's storage version migrator

Discussion:
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <ins> Ensure that your cluster has the `StorageVersionMigrator` and `InformerResourceVersion` [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) enabled. You will need control plane administrator access to make that change. Enable storage version migration REST api by setting runtime config `storagemigration.k8s.io/v1alpha1` to `true` for the API server. For more information on how to do that, read [enable or disable a Kubernetes API](/docs/tasks/administer-cluster/enable-disable-api/). </ins> <!-- steps --> ## Re-encrypt Kubernetes secrets using storage version migration
Change:
This is bug report There is wrong link referring to the page in Default StorageClass Problem in Default StorageClass , there is which is redirecting to the wrong source Solution update with valid link Page to update
/sig docs /language en /assign
/triage accepted
fixed this issue in PTAL!!
/kind bug

Discussion:
used. If you set the <del> [`storageclass.kubernetes.io/is-default-class`](/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) </del> <ins> [`storageclass.kubernetes.io/is-default-class`](/docs/reference/labels-annotations-taints/#storageclass-kubernetes-io-is-default-class) </ins> annotation to true on more than one StorageClass in your cluster, and you then create a PersistentVolumeClaim with no `storageClassName` set, Kubernetes uses the most recently created default StorageClass.
Change:
There is minor fault in the webpage : The indent is wrong egress: to: namespaceSelector: matchExpressions: key: namespace operator: In values: ["frontend", "backend"] This fault only exist in the chinese version of this page, it should be corrected as english version as below: egress: to: namespaceSelector: matchExpressions: key: namespace operator: In values: ["frontend", "backend"]
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
Why would you say it is "wrong"? List items can be indented in either way.
I created two versions yaml, 1.yaml for chinese version and 2.yaml for english version: ! So matchExpressions should be indented. Meanwhile, although one whitespace indent is ok in yaml, it's good to use two whitespace indent as habits of most people.
I agree with the observations regarding the indentation in the Chinese version of the documentation and think it needs a fix.
/language zh /sig docs /sig node
Please paste your snippet into a code block, i.e. your yaml here ` I can guess what you are suggesting here, but need a confirmation.
Please check if is the fix you are suggesting.
Yes, I think it's fixed, thank you!

Discussion:
matchLabels: app: myapp policyTypes: <del> - Egress </del> <ins> - Egress </ins> egress: <del> - to: - namespaceSelector: matchExpressions: - key: namespace operator: In values: ["frontend", "backend"] </del> <ins> - to: - namespaceSelector: matchExpressions: - key: namespace operator: In values: ["frontend", "backend"] </ins> ``` {{< note >}}
Change:
When running this command: The grace period it was going to sleep was 1800s (30m), so after all resources were deleted (about 5-6s), I hit Ctrl-C, then manually ran the line after the sleep: kubectl delete persistentvolumeclaim -l app=cassandra Recommend adding a note to avoid having the student wait 30m for a command to finish that might only take a few seconds.
Related page: /language en
I think we can improve the advice, or change the grace period to be quite a bit shorter. Not sure which is better.
/triage accepted either way
/retitle [Unclear] example: Deploying Cassandra with a StatefulSet
I have tried to reproduce the issue with a grace period of 300 seconds. And I observed that all my related resources were deleted in under 10 seconds. It will be better if we reduce the to some shorter value like or .
I would like to work on this issue. /assign /sig apps /sig storage
/assign

Discussion:
labels: app: cassandra spec: <del> terminationGracePeriodSeconds: 1800 </del> <ins> terminationGracePeriodSeconds: 500 </ins> containers: - name: cassandra image: gcr.io/google-samples/cassandra:v13
Change:
As per title the following page contains a broken link to discovery document. See highlight here:
Page reported in issue: /language en /kind bug
/sig docs
I want to work on that. /assign
fixed this issue in PTAL!!

Discussion:
response for the `/api` and `/apis` endpoint is an unaggregated discovery document. <del> The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2.json) </del> <ins> The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json) </ins> for the built-in resources can be found in the Kubernetes GitHub repository. This Github document can be used as a reference of the base set of the available resources if a Kubernetes cluster is not available to query.