jiebi/CodeConvo huggingface dataset:
Code change:
To demonstrate this, let's spin up a simple Deployment and Pods in the `development` namespace. ```shell <del> kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname  -n=development </del> <ins> kubectl create deployment snowflake --image=k8s.gcr.io/serve_hostname -n=development </ins> kubectl scale deployment snowflake --replicas=2 -n=development ``` We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname. <del> Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead. If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details. </del> ```shell kubectl get deployment -n=development

Related discussion:
text: This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: After creating and scaling deployment using command kubectl create deployment cattle -- kubectl scale deployment cattle --replicas=5 When we execute below command to list pods with options -l kubectl get pods -l run=cattle O/P is No resources found in production namespace. Proposed Solution: kubectl get pods -l app=cattle Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
can you / have you confirmed that this is a bug? If so, it's be good to record this issue as /kind bug
Yes, this is a bug. When was changed to , the label should have changed from to . This needs to be updated on a couple of other pages as well. /kind bug
/priority backlog
Code change:
/docs/api-reference/v1/operations/     /docs/api-reference/v1.9/ 301 /docs/concepts/abstractions/controllers/garbage-collection/     /docs/concepts/workloads/controllers/garbage-collection/ 301 <del> /docs/concepts/abstractions/controllers/petsets/     /docs/concepts/workloads/controllers/statefulset/ 301 </del> /docs/concepts/abstractions/controllers/statefulsets/     /docs/concepts/workloads/controllers/statefulset/ 301 /docs/concepts/abstractions/init-containers/     /docs/concepts/workloads/pods/init-containers/ 301 /docs/concepts/abstractions/overview/     /docs/concepts/overview/working-with-objects/kubernetes-objects/ 301

Related discussion:
text: This is a... [ ] Feature Request [x] Bug Report Problem: There is a link missing that was supposed to be in section Differences between alpha PetSets and beta StatefulSets under it in the second point StatefulSet guards against split brain which ends with following text TODO: Link to doc about fencing. Change it and add the link that is required. Proposed Solution: Add link which is missing Page to Update:
PetSet has long been replaced by StatefuSet and StatefulSet has been GA'ed in 1.9. So we are going to remove this page to avoid further confusion.
Code change:
h4, h4.alert-heading { color: #000; display: block; <del> float: left; </del> <ins> float: initial; </ins> font-size: 1rem; padding: 0; padding-right: 0.5rem;

Related discussion:
text: This is a Bug Report Problem: Using as an example, Note blocks that start with a bullet appear malformed, same outcome in both Chrome and Safari, note the dot over the e characters and incorrect indentation - <img width="723" alt="image" src=""Proposed Solution: Let's discuss further, possibly, maybe this can be fixed via hugo, otherwise we could investigate an update to all affected pages. Page to Update: We should update all notes that meet this criteria, investigate after a proposed solution is agreed.
/area web-development
It seems that our recent update to align with Docsy-style callouts in may have unintentionally caused this issue. There's definitely room for improvement here, and we should address this to ensure the content is displayed properly. /priority backlog /triage accepted
Oops. I think we can address this with a CSS fix; for example, not making the “note” text an inline block when the parent contains either or (using and selectors). For a simple fix, make the “Note:” text never be an inline block.
i would like to try
/assign
Code change:
} body.cid-community .community-section#values { <del> width: 100vw; </del> <ins> width: 100%; </ins> max-width: initial; background-image: url('/images/community/event-bg.jpg'); color: #fff;

Related discussion:
text: This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Proposed Solution: Page to Update: /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
During my browsing of the docs on a mobile device, I came across a similar situation on another page, specifically in the . It seems this issue might be widespread and could be affecting multiple pages, not limited to just the community page. Perhaps we could explore identifying a CSS fix that enhances the rendering of pages with wider elements. This way, we can efficiently resolve the problem and improve the overall user experience.
/area web-development
I tried making some changes on the source, A simple overflow - x in the right places seems to solve the problem. ! However, I'd often come across such problems when the scaling isn't managed properly. I'm sure there are better ways to get this problem fixed.
I see, In that case I'll try to find anymore pages that might be having the same issue.
Similar issue is present in case study
Code change:
* `Localhost` to use a profile loaded on the host (see below) * `Unconfined` to run without AppArmor <del> See the [API Reference](#api-reference) for the full details on the AppArmor profile API. </del> <ins> See [Specifying AppArmor Confinement](#specifying-apparmor-confinement) for full details on the AppArmor profile API. </ins> To verify that the profile was applied, you can check that the container's root process is running with the correct profile by examining its proc attr:

Related discussion:
text: This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In the , under redirects to a topic that has been removed in release 1.30 by this PR Therefore, the hyperlink no longer exists. was replaced with Proposed Solution: Replace this line in with this line and adding a hyperlink for Specifying Apparmor Confinement: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--If the suggested solution is okay. I can raise a PR for it.
/assign /sig node /language en /sig docs
/triage accepted /priority backlog
Code change:
<td> <p><code>localAPIEndpoint</code> represents the endpoint of the API server instance that's deployed on this control plane node. In HA setups, this differs from <code>ClusterConfiguration.controlPlaneEndpoint</code> <del> in the sense that <code>ontrolPlaneEndpoint</code> is the global endpoint for the cluster, which then </del> <ins> in the sense that <code>controlPlaneEndpoint</code> is the global endpoint for the cluster, which then </ins> loadbalances the requests to each individual API server. This configuration object lets you customize what IP/DNS name and port the local API server advertises it's accessible on. By default, kubeadm tries to auto-detect the IP of the default

Related discussion:
text: found typo "ontrolPlaneEndpoint" in the below <img width="862" alt="typo ontrolPlaneEndpoint" src=""There is a typo "ontrolPlaneEndpoint" in the localAPIEndpoint description it should be "controlPlaneEndpoint"
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
Page related to issue: /language en
/retitle Typo in auto-generated "kubeadm Configuration (v1beta4)" reference page
The mentioned reference page for "kubeadm Configuration (v1beta4)" is . The page is generated from the upstream source code . As the page is generated from the upstream source code, any fixes would need to be addressed there. For those interested in contributing to resolve this issue, please refer to the upstream contribution guidelines outlined at:
/sig docs
this is not a typo in the code files and also in my browser it's shown as controlPlaneEndpoint, so maybe it's a rendering issue. ! cc
but again, there are no typos in the code / go docs. also NOTE that v1beta4 is WIP API that should not be used yet by users.
the in is also dropped in another place on that page, screenshot below. I'm not familiar with the autogeneration for these pages, is there some processing on the word that is dropping letters when converting from the original? Looks like in the source file its written with a capital and in the generated file its with a lower case. Not sure why it would only so it sometimes though. We should check to see if this is happening on other pages. /priority awaiting-more-evidence <img width="789" alt="Screenshot 2024-03-27 at 9 44 26 AM" src=""
Another interesting observation looking at the - it appears to only happen on the v1beta4 version of the docs, not the previous versions. Looks like it was modified with .
Put up a fix in . It looks like this wasn't from an autogeneration error and just a simple typo when the docs were updated for v1beta4.
Code change:
Sebagai contoh, untuk membuat sebuah Secret dari literal `username=admin` dan `password=secret`, kamu dapat menspesifikasikan _generator_ Secret pada _file_ `kustomization.yaml` sebagai ```shell <del> # Membuat sebuah file kustomization.yaml dengan menggunakan SecretGenerator </del> <ins> # Membuat sebuah berkas kustomization.yaml dengan menggunakan SecretGenerator </ins> $ cat <<EOF >./kustomization.yaml secretGenerator: - name: db-user-pass

Related discussion:
text: This issue is intended for contributor workshop as part of Cloud Native Day Indonesia on 7th Nov 2020. Please don't take it if you are not part of the workshop. There are several old translated pages that contain the english glossary "file", supposed to use Indonesian "berkas" as per KBBI. Please claim the task to fix them by giving comments on this Github issue. /language id Tasks to fix "file" -"berkas": [x] docs/tasks/manage-kubernetes-objects/imperative-[x] docs/tasks/manage-kubernetes-objects/declarative-[ ] docs/tasks/manage-kubernetes-objects/imperative-[ ] docs/tasks/configure-pod-container/configure-pod-[ ] docs/tasks/administer-cluster/sysctl-[ ] [x] [ ] docs/concepts/storage/storage-[ ] docs/concepts/services-networking/connect-applications-[ ] docs/concepts/services-[x] [x] docs/concepts/cluster-
/triage accepted
/assign
I'm taking this page docs/tasks/manage-kubernetes-objects/imperative-
/reopen
Reopened this issue. <detailsIn response to : /reopen 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'm taking this page docs/tasks/manage-kubernetes-objects/declarative-
may i change this file:
thanks feel free to raise the PR and link this issue
/reopen
Reopened this issue. <detailsIn response to : /reopen 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 take this page :
please let me change another part. I will try to change this file
sure just mention this issue number when you raise the pull request /reopen
Reopened this issue. <detailsIn response to : please let me change another part sure just mention this issue number when you raise the pull request 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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close.
Code change:
Sebagai contoh, untuk membuat sebuah Secret dari literal `username=admin` dan `password=secret`, kamu dapat menspesifikasikan _generator_ Secret pada _file_ `kustomization.yaml` sebagai ```shell <del> # Membuat sebuah file kustomization.yaml dengan menggunakan SecretGenerator </del> <ins> # Membuat sebuah berkas kustomization.yaml dengan menggunakan SecretGenerator </ins> $ cat <<EOF >./kustomization.yaml secretGenerator: - name: db-user-pass

Related discussion:
text: If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
Code change:
display: block; height: 100%; position: fixed; <del> width: 100%; z-index: 1; </del> top: 0; left: 0; background-color: rgba(51, 113, 227, 3%); border-right: 1px solid #dee2e6; <del> overflow-x: hidden; </del> <ins> overflow-x: scroll; </ins> padding-top: .5rem; }

Related discussion:
text: This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Using chrome (120.0.6099.129 (Official Build) (x86_64)) on macOS (12.7.1 (21G920)) and hitting the link from the , I hit the documentation for Kubernetes 1.29 and I can only see the navigation with the list of objects. <img width="1595" alt="image" src=""I have observed the same problem on safari ( 17.1.2 (.2.9.11.12, )): <img width="1587" alt="image" src=""And Firefox (121.0 (64-bit)): <img width="1266" alt="image" src=""Proposed Solution: Get the content back as in the : <img width="1585" alt="image" src=""Page to Update:
/retitle One-page API reference missing for Kubernetes v1.29
The API reference for v1.29 was successfully generated in PR , as evidenced by the verified information in the . It appears that we're encountering a rendering glitch.
Upon further investigation, it seems that the page data isn't rendering correctly in dark mode (sort of). I switched my device/browser theme to light mode, and the page info became visible (Refer below screenshot). It seems like there might be some missing CSS and scripts causing this issue. <img width="1278" alt="api-refence-light-mode" src=""
This is definitely something we should address. (cc: /triage accepted
/retitle Content of 'One-page API Reference for v1.29' not rendering properly in dark mode
/assign
The original description of the issue is proper and correct, I don't know why you are so akin to change these issue descriptions. I'm raising this question because when an issue title is changed, my email client won't treat the issues as the same one. The "conversation" mode no longer works. I'm receiving emails for every comment as a separate email. It is not a big deal but it is really annoying.
Code change:
display: block; height: 100%; position: fixed; <del> width: 100%; z-index: 1; </del> top: 0; left: 0; background-color: rgba(51, 113, 227, 3%); border-right: 1px solid #dee2e6; <del> overflow-x: hidden; </del> <ins> overflow-x: scroll; </ins> padding-top: .5rem; }

Related discussion:
text: Ah, does the API reference have special support for dark mode, separate from Assuming that this is the case: /kind bug /area web-development A short-term fix would be to drop the dark mode support, pending an implementation that works right. Let's see if sorts it out.
For what it's worth, I agree with the title change in The bug was about dark mode rendering and not that the reference was completely missing.
Code change:
## The Kubernetes network model <del> Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address. </del> <ins> Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address (one address per IP address family). </ins> This means you do not need to explicitly create links between `Pods` and you almost never need to deal with mapping container ports to host ports. This creates a clean, backwards-compatible model where `Pods` can be treated

Related discussion:
text: Page to be updated: What needs to be done? section needs to be updated per and For technical accuracy and/or reference, you may also check PR /sig network /help /good-first-issue cc:
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 : Page to be updated: For technical accuracy and/or reference, you may also check PR /help /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 am beginner and i want to contribute on this issue. Can you please guide me for this issue??
Sure, Please read and . After going through both of the resources, please could you let us know what more information would you need from our side to begin working on this issue?
can I work on this issue?
Hello everyone! Anyone looking at the issue - please note that you do not need my/anyone else's permission to work on an issue. If you are signing the and abide by the please feel free to pick up the issue. Additionally, please note that for every issue under sig docs it's always OK for anyone to open a pull request to work on it, including this one. If starting work, it's nevertheless polite to try to liaise with anyone who has already opened a PR or otherwise expressed an intention to work on the issue.
/triage accepted /priority backlog
i checked the both and . but i haven’t find any difference in actual documentation. it seems correct to me. would you like elaborate me.
Both those comments point to a change that is required in the Kubernetes Network Model section. The current phrasing is not technically accurate. For reference, you ALSO need to check the PR because it will give you the correct phrasing.
/assign
/assign
/assign
/assign
Code change:
snowflake    2/2     2            2           2m ``` ```shell <del> kubectl get pods -l run=snowflake -n=development </del> <ins> kubectl get pods -l app=snowflake -n=development </ins> ``` ``` NAME                         READY     STATUS    RESTARTS   AGE

Related discussion:
text: This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: After creating and scaling deployment using command kubectl create deployment cattle -- kubectl scale deployment cattle --replicas=5 When we execute below command to list pods with options -l kubectl get pods -l run=cattle O/P is No resources found in production namespace. Proposed Solution: kubectl get pods -l app=cattle Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
can you / have you confirmed that this is a bug? If so, it's be good to record this issue as /kind bug
Yes, this is a bug. When was changed to , the label should have changed from to . This needs to be updated on a couple of other pages as well. /kind bug
/priority backlog
Code change:
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

Related discussion:
text: 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