jiebi/CodeConvo huggingface dataset:
Change:
I was following the instructions on . When I download the kubectl convert plugin, it gives me this error. !
Hi The URL used by you is wrong. In your URL you put a backslash in two places one is after $ and the second after see below: Correct one is:
For me, there seems no backslashes in the command, ! but when I copy that and paste, the backslashes appear. ! (Copied in Windows 10 x64, Chrome 97.0.4692.71, pasted to the Oracle Virtualbox VM, Ubuntu 18.04 desktop x64, bundled Terminal app) In that page, replacing to might resolve the problem. ! (This one causes no problem.) /kind bug /triage accepted
Hi when I do copy and paste it, the backslash does not appear in the command.
Maybe automatically adds backslashes.. I am using , and I guess that is using too. ( Is this correct? ) And It seems that you are using other than , Is this correct? If these are correct, then I guess that replacing to will cause no problem on , , and so on.
Hi yes, I am using the bash, maybe it is with zsh. I tried this command and it is also working, so we can replace the command with
/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 : /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
Yup, I am using zsh as well
/assign
GitHub didn't allow me to assign the following users: championshuttler. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /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
/assign

Discussion:
1. Download the latest release with the command: ```bash <del> curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert </del> <ins> curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert" </ins> ``` 1. Validate the binary (optional)
Change:
I created a new deployment "mydeploy-dotnetcounters" with two containers, one with resource request and limit set and one without. The new deployment had these labels: The HPA for a different deployment "mydeploy" started to fail with: The "mydeploy" deployment had these labels: I resource request and limit to the second container in the "mydeploy-dotnetcounters" deployment and the HPA for "mydeploy" recovered. It seems that the HPA decide what pod to check based on what labels match. However these is no mention of that mechanism in the HPA documentation ( that I could find ). Not here: And not here: I expect the HPA for one deployment to not be affected by the configuration of another deployment. I expect that I can read about the mechanism by which an HPA decides which pods' metrics to examine. Create a deployment with an HPA. Create a second deployment that is a clone of the first, but with an additional label and with resource request cpu not set. No response <details</details<detailsGKE v1.20.11-gke.1300 </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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
/sig docs
/sig autoscaling
This really belongs in the repo /transfer website
/language en /triage accepted /priority backlog /kind feature Thanks for the suggestion
/assign

Discussion:
(and the default interval is 15 seconds). Once during each period, the controller manager queries the resource utilization against the <del> metrics specified in each HorizontalPodAutoscaler definition.  The controller manager obtains the metrics from either the resource metrics API (for per-pod resource metrics), </del> <ins> metrics specified in each HorizontalPodAutoscaler definition.  The controller manager finds the target resource defined by the `scaleTargetRef`, then selects the pods based on the target resource's `.spec.selector` labels, and obtains the metrics from either the resource metrics API (for per-pod resource metrics), </ins> or the custom metrics API (for all other metrics). * For per-pod resource metrics (like CPU), the controller fetches the metrics
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: There ~is~ soon will be an out of band v1.23.3 release - see - and the releases page should mention it. Proposed Solution: Update the releases page to mention v1.23.3 To change that, edit the data within Pages to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.23.3 Additional Information: /sig release /priority important-soon
/remove-kind bug
Related to
Hi, I would like to work on this issue. /assign
/area release-eng
/triage accepted
now is out of date as v1.23.3 is live - see

Discussion:
schedules: - release: 1.23 releaseDate: 2021-12-07 <del> next: 1.23.3 cherryPickDeadline: 2022-01-24 targetDate: 2022-01-25 </del> <ins> next: 1.23.4 cherryPickDeadline: 2022-02-11 targetDate: 2022-02-16 </ins> endOfLifeDate: 2023-02-28 previousPatches: <ins> - release: 1.23.3 cherryPickDeadLine: 2022-01-24 targetDate: 2022-01-25 note: "Out-of-Bound Release https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY" </ins> - release: 1.23.2 cherryPickDeadline: 2022-01-14 targetDate: 2022-01-19
Change:
Hi. On this section of the french Ingress documentation, , there seems to be a dead link at la specification de la ressource ingress. French version seems outdated in comparaison with the english one. Cheers
Thank you for reporting this The correct link should be: /triage accepted /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 : Thank you for reporting this /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
I would like to take this up.
/retitle [fr] Broken link in docs/concepts/services-networking/ingress/
/assign Thank you :)
/language fr /kind bug

Discussion:
est l'annotation [rewrite-target](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md). Différents [Ingress controller](/docs/concepts/services-networking/ingress-controllers) prennent en charge différentes annotations. Consultez la documentation du contrôleur Ingress de votre choix pour savoir quelles annotations sont prises en charge. <del> La [spécification de la ressource Ingress](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il </del> <ins> La [spécification de la ressource Ingress](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) dispose de toutes les informations nécessaires pour configurer un loadbalancer ou un serveur proxy. Plus important encore, il </ins> contient une liste de règles d'appariement de toutes les demandes entrantes. La ressource Ingress ne supporte que les règles pour diriger le trafic HTTP.
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 volume mount mechanism in Kubernetes used to rely on an unregistered annotation. That annotation () is already document, but isn't yet registered. Proposed Solution: Add to (list it as deprecated) 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
You can refer to for details of what the annotation does. Also the text of the annotation description should in any case hyperlink to so that readers can learn about the mechanism that replaced it.
/sig storage I would like to give a try.
/sig storage /assign
/triage accepted

Discussion:
This annotation has been deprecated. <ins> ### volume.beta.kubernetes.io/mount-options (deprecated) {#mount-options} Example : `volume.beta.kubernetes.io/mount-options: "ro,soft"` Used on: PersistentVolume A Kubernetes administrator can specify additional [mount options](/docs/concepts/storage/persistent-volumes/#mount-options) for when a PersistentVolume is mounted on a node. This annotation has been deprecated. </ins> ### volume.kubernetes.io/storage-provisioner Used on: PersistentVolumeClaim
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 The example works well for a single-container pod. However, it is important for multi-container pods to know which container failed. The following command would show which container failed within the pod: Why is this needed Because the current command only shows the error message, not which container is failing — thus confusing if it is a multi-container pod. This change will hopefully help people running multi-container pods figuring out the faulty container. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --None.
/language en /triage accepted /priority backlog
/assign
Hello developers! I want to contribute to this issue and give info about multi-container. If anyone can guide me to the resources, it would be really helpful.
Hello , thanks for your help. You can take a look at the PR created , and see if you find anything odd. If so, please comment or add a patch to it. Thanks!
Okay!

Discussion:
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" <ins> If you are running a multi-container pod, you can use a Go template to include the container's name. By doing so, you can discover which of the containers is failing: ```shell kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:n%snn" .name .lastState.terminated.message}}{{end}}' ``` </ins> ## Customizing the termination message Kubernetes retrieves termination messages from the termination message file
Change:
This is a Bug Report Problem: Documentation for cli tool kube-apiserver ] references flag which doesn't exist. The intended documentation should reference the flag. The cli tool implementation ] also has an incorrect doc-string ]. I'll make cross-referencing issues for both projects Proposed Solution: All references to the should be updated to Page to Update: Kubernetes Versions: Additional Information: Issue and PR on the kubernetes/kubernetes project are:
/assign /triage accepted
/retitle Documentation references --service-account-signing-key flag that doesn't exist
This is now essentially a duplicate of

Discussion:
<td colspan="2">--service-account-key-file strings</td> </tr> <tr> <del> <td></td><td style="line-height: 130%; word-wrap: break-word;"><p>File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key is provided</p></td> </del> <ins> <td></td><td style="line-height: 130%; word-wrap: break-word;"><p>File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key-file is provided</p></td> </ins> </tr> <tr>
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 an annotation, , that is not registered or documented. Proposed Solution: Register and document this annotation. Page to Update: Also consider whether to mention that annotation in Additional Information: /sig auth /language en
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 work on this.
/assign

Discussion:
It is populated when adding `--record` to a `kubectl` command that may change an object. <ins> ## kubernetes.io/description {#description} Example: `kubernetes.io/description: "Description of K8s object."` Used on: All Objects This annotation is used for describing specific behaviour of given object. </ins> ## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} Example: `controller.kubernetes.io/pod-deletion-cost=10`

The tutorial [Restrict a Container's Syscalls with seccomp](/docs/tutorials/clusters/seccomp/) takes you through the steps you follow to apply a seccomp profile to a Pod or to one of its containers. That tutorial covers the supported mechanism for configuring seccomp in Kubernetes, <del> based on setting `securityContext` within the Pod's `.spec`. </del>  No newline at end of file <ins> based on setting `securityContext` within the Pod's `.spec`. </ins>
Change:
For the Redhat when upgrading the kubelet you should have following for Restart kubelet sudo systemctl daemon-reload sudo systemctl stop kubelet ps -ef | grep kubelet (verfiy kubelet stopped kill process if not stopped) sudo systemctl start kubelet
hi, i'm not sure what issue you are reporting. can you elaborate? /kind support
/triage needs-information
/sig cluster-lifecycle I think is asking for a detailed walkthrough of how to restart a service on RedHat-like hosts, and then to verify that the restarted service is healthy. There's some value in this but also we need to bear in mind that systemd and Linux are not the only options for nodes, and that we could instead declare “you should know how to restart services and verify that they are healthy” as a prerequisite. Any Kubernetes-specific way to verify that a kubelet is healthy is valid and we should document it.
Hey can I work on this issue?
we could add the following bullet point here: would you like to send a PR for that?
/kind feature /remove-triage needs-information /triage accepted /retitle kubeadm-upgrade: add note about verifying the kubelet service status
/assign

Discussion:
they could be running CoreDNS Pods or other critical workloads. For more information see [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/). - All containers are restarted after upgrade, because the container spec hash value is changed. <ins> - To verify that the kubelet service has successfully restarted after the kubelet has been upgraded, you can execute `systemctl status kubelet`  or view the service logs with `journalctl -xeu kubelet`. </ins> <!-- steps -->
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 of , the link ' in XFS' is broken. It returns 404 Not Found. Proposed Solution: Page to Update: File to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/triage accepted
I think we can link to this : . Thoughts?
/language en sure - would you like to open a pull request?
/assign

Discussion:
* Get hands-on experience [assigning CPU resources to containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). * Read how the API reference defines a [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) and its [resource requirements](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources) <del> * Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS </del> <ins> * Read about [project quotas](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F) in XFS </ins> * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
Change:
I don't have any issue .but i have suggestion . when i follow the official guide i noticed a document incorrect path issue. In the steps 7 they mention in /tmp folder all the etcd instance. but steps 6 showing in the only $HOST0 having tmp other etcd instance having document root. Document should update the correct path !
/language en /sig cluster-lifecycle I don't think I've understood the report you've filed In the existing page, which specific part of that text contains the details that you think we should change?
Hi In the step 7 path should be correct as below root {HOST0} root root
if you look at step 4: all files are under ~so it seems step 6 is the one that is wrong.~ EDIT: never mind the copied files end up in HOME with scp.
/assign
/kind bug /triage accepted
fix here:

Discussion:
```sh root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml <del> root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml </del> <ins> root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml </ins> ``` 1. Optional: Check the cluster health
Change:
This is a Bug Report Problem: Regarding , I found the similar broken links on other pages. English pages have already been fixed. ref: ru pages also need to be fixed. Proposed Solution: Fixes broken links including {{< param "githubbranch" }} to master. In the case of link to , fixes to {{< param "fullversion" }}. ref:
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:
Любой код, больший или равный 200 и меньший 400, означает успех. Любой другой код интерпретируется как ошибка. Вы можете посмотреть исходные коды сервера в <del> [server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go). </del> <ins> [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go). </ins> В течение первых 10 секунд жизни контейнера обработчик `/healthz` возвращает статус 200. После обработчик возвращает статус 500.
Change:
This is a Bug Report Problem: Regarding , I found the similar broken links on other pages. English pages have already been fixed. ref: it pages also need to be fixed. Proposed Solution: Fixes broken links including {{< param "githubbranch" }} to master. In the case of link to , fixes to {{< param "fullversion" }}. ref:
/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:
`kubectl logs` restituirà una risposta vuota. {{< /note >}} <del> [cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh </del> <ins> [cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh </ins> ### System component logs

Gli esempi che abbiamo utilizzato fino ad ora si applicano al massimo una singola etichetta a qualsiasi risorsa. Esistono molti scenari in cui è necessario utilizzare più etichette per distinguere i set l'uno dall'altro. <del> Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette: </del> <ins> Ad esempio, diverse applicazioni utilizzerebbero valori diversi per l'etichetta `app`, ma un'applicazione multilivello, come l'esempio [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/), avrebbe inoltre bisogno di distinguere ogni livello. Il frontend potrebbe contenere le seguenti etichette: </ins> ```yaml labels:
Change:
There is a translation error here. " " should be changed to " ".
/kind bug /language zh /triage accepted /assign

Discussion:
<!-- 1.  Generate the server certificate using the ca.key, ca.crt and server.csr: --> <del> 1.  基于 ca.key、ca.key 和 server.csr 等三个文件生成服务端证书： </del> <ins> 1.  基于 ca.key、ca.crt 和 server.csr 等三个文件生成服务端证书： </ins> openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key  -CAcreateserial -out server.crt -days 10000