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: There's either a typo in the of Module 2 of the tutorial, or the sentence is very awkwardly worded. The sentence: Once you've created a Deployment, the Kubernetes master schedules mentioned application instances onto individual Nodes in the cluster. doesn't appear to make any sense. Is the Kubernetes master scheduling the "mentioned application instances"? What application instances were mentioned? What does "scheduling" in this context mean? Proposed Solution: If this sentence is written as intended, it could use clarification. However it seems like there might be one or more typos, where words have been accidentally substituted. Those substitutions should be corrected if that's the case. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
I think the sentence is true. It looks like there is room to clarify and improve the wording. explains scheduling in a Kubernetes context. <hr /Does this wording work better ?
I think that's an improvement and I believe I understand the sentence as intended now. I think my confusion largely stemmed from the word "mentioned." My understanding now is that "mentioned application instances" in this context means "the application instances mentioned in the Deployment you've created," right? So maybe: I think "scheduling" might be another point of confusion, just because it's only been mentioned in the tutorial once before: . It might not be necessary to give an expanded definition of scheduling here, but I do think the phrasing used in that previous mention of scheduling is more accessible: "schedules ... to run on the cluster's nodes" rather than "schedules ... onto individual Nodes". "Scheduling something" is a familiar phrase, but "scheduling something onto something" is a little less clear at first. So then maybe: ?
- would you also be interesting in proposing that fix as a pull request?
Done!

Discussion:
Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes <b>Deployment</b> configuration. The Deployment instructs Kubernetes how to create and update instances of your application. Once you've created a Deployment, the Kubernetes <del> master schedules mentioned application instances onto individual Nodes in the cluster. </del> <ins> master schedules the application instances included in that Deployment to run on individual Nodes in the cluster. </ins> </p> <p>Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances. If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster. <b>This provides a self-healing mechanism to address machine failure or maintenance.</b></p>
Change:
This is a Bug Report Problem: The page at currently contains the confusing sentence fragment: "An admin distributing private keys, a user store like Keystone or Google Accounts, even a file with a list of usernames and passwords." Proposed Solution: Probably, connect the preceding sentence and this fragment. (It looks like the fragment is examples of what the preceding sentence refers to.) Page to Update:
/language en /kind bug /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /language en /kind bug /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

Discussion:
All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users. <del> Normal users are assumed to be managed by an outside, independent service. An admin distributing private keys, a user store like Keystone or Google Accounts, even a file with a list of usernames and passwords. In this regard, _Kubernetes does not have objects which represent normal user accounts._ Normal users cannot be added to a cluster through an API call. </del> <ins> It is assumed that a cluster-independent service manages normal users in the following ways: - an administrator distributing private keys - a user store like Keystone or Google Accounts - a file with a list of usernames and passwords In this regard, _Kubernetes does not have objects which represent normal user accounts._ Normal users cannot be added to a cluster through an API call. </ins> Even though normal user cannot be added via an API call, but any user that presents a valid certificate signed by the cluster’s certificate authority (CA) is considered authenticated. In this configuration, Kubernetes determines the username from the common name field in the ‘subject’ of the cert (e.g., “/CN=bob”). From there, the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource. You can refer to [creating user certificate request](/docs/reference/access-authn-authz/certificate-signing-requests/#user-csr) for more details about this.
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 page has a cautionary note about a prerequisite: this note belongs on the page, however the best place for it is in the Prerequisites section. Proposed Solution: Edit the page to move the caution note to be the very first thing inside the prerequisites section. Page to Update: /language en /kind cleanup /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The page has a cautionary note about a prerequisite: Caution: For the Ingress resource to work, the cluster must also have an Ingress controller running. Edit the page to move the caution note to be the very first thing inside the prerequisites section. /kind cleanup /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
If you are looking to work on this and would like help, please reply here. I'll watch for replies.
Isn't there an effort underway to move minikube related pages onto the minikube site? and
I can work on this one! Should I?
I am looking to start contributing. looks like ..I can start with this.
Go for it! Contributions welcome. Bear in mind when it comes to deciding if you want to work on this. I think this example only happens to use Minikube; a separate PR could rework it to explain how to try out Ingress with a different kind of learning environment.
I'm reviewing the content and looks like the tutorial is explaining how to deploy the Ingress Controller, which is exactly what the caution note is mentioning. IMHO, the caution node should be removed instead of moved to other section.
another good point is that is saying the user could use Kubernetes playgrounds (Katacoda, play-with-k8s) which are not Minikube.
Sure, it's OK to remove the caution note. sounds like it could be a new separate issue(?)

Discussion:
{{% capture overview %}} An [Ingress](/docs/concepts/services-networking/ingress/) is an API object that defines rules which allow external access <del> to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress. {{< caution >}} For the Ingress resource to work, the cluster **must** also have an Ingress controller running. {{< /caution >}} </del> <ins> to services in a cluster. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers/) fulfills the rules set in the Ingress. </ins> This page shows you how to set up a simple Ingress which routes requests to Service web or web2 depending on the HTTP URI.
Change:
UI issues with page !
would you like sending a PR to fix the formatting of the page? /kind bug /sig windows cluster-lifecycle cc
Done but I never did it before so not sure if I did it correctly
If you send a PR in it will have a netlify preview that you can verify with. We should have checked that on the last one.

Discussion:
{{< /note >}} {{< note >}} <del> If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" ``` in the flannel-host-gw.yml or flannel-overlay.yml file and specify your interface accordingly. </del> <ins> If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" ``` in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly. ```bash # Example curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` </ins> {{< /note >}} <del> ```bash # Example curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` </del> ### Joining a Windows worker node
Change:
This is a Bug Report Problem: When building kubernetes-hugo it can fail with below error because build process can't access internet. By default docker build use bridge network to reach Internet which is not always correct assumption. The same problem can be seen reported in few other places: Error: [root website]# make docker-image docker build . --tag kubernetes-hugo --build-arg HUGOVERSION=0.59.1 Sending build context to Docker daemon 3.584kB Step 1/7 : FROM alpine:latest --- Step 2/7 : LABEL maintainer="Luc Perkins " ---Using cache --- Step 3/7 : RUN apk add --no-cache curl git openssh-client rsync build-base libc6-compat ---Running in fetch http://dl- WARNING: Ignoring http://dl- temporary error (try again later) fetch http://dl- WARNING: Ignoring http://dl- temporary error (try again later) ERROR: unsatisfiable constraints: build-base (missing): required by: world[build-base] curl (missing): required by: world[curl] git (missing): required by: world[git] libc6-compat (missing): required by: world[libc6-compat] openssh-client (missing): required by: world[openssh-client] rsync (missing): required by: world[rsync] The command '/bin/sh -c apk add --no-cache curl git openssh-client rsync build-base libc6-compat' returned a non-zero code: 6 make: [Makefile:39: docker-image] Error 6 Proposed Solution: It would be more reliable to use docker host network instead of bridge network. For building kubernetes-hugo, it doesn't really matter which network is used to pull all artifacts. And docker host network almost always guarantees access to Internet. Page to Update: N/A Version:* Problem can be seen on latest master.

Discussion:
hugo server --buildFuture docker-image: <del> $(DOCKER) build . --tag $(DOCKER_IMAGE) --build-arg HUGO_VERSION=$(HUGO_VERSION) </del> <ins> $(DOCKER) build .  --network=host  --tag $(DOCKER_IMAGE)  --build-arg HUGO_VERSION=$(HUGO_VERSION) </ins> docker-build: $(DOCKER_RUN) $(DOCKER_IMAGE) hugo
Change:
This is a Bug Report Problem: The getting started guide doesn't work on CentOS 7.7.1908. The section Installing kubeadm, kubelet and kubectl contains an error in this line: Whereas is not defined. Proposed Solution: Replace with Page to Update:
Ah I'm wrong /remove-kind bug /remove-good-first-issue /remove-priority important-longterm /triage support
What's the error on CentOS 7.7.1908 YUM usually lets you use and other built-in variables in a repository configuration.
/remove-good-first-issue
/remove-help
The error is: As it seems is evaluated to "" BTW, returns empty as well.
Hmm. Try this: What's the output?
Loaded plugins: fastestmirror {'arch': 'ia32e', 'basearch': 'x86_64', 'contentdir': 'centos', 'infra': 'stock', 'releasever': '7', 'uuid': '-e4c7-4444-9d2f-'}
Looks like is set in YUM. The problem is that the page instructs the reader to use a “here document” to edit the YUM configuration. /remove-triage support /kind bug /sig cluster-lifecycle /priority important-soon thanks for clarifying.

Discussion:
cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes <del> baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch </del> <ins> baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch </ins> enabled=1 gpgcheck=1 repo_gpgcheck=1
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: has a feature-state shortcode: this shortcode doesn't track when the feature went beta. Proposed Solution: Change that line to: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /help /language en /priority backlog /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: has a feature-state shortcode: Change that line to: <!--Kubernetes Version:--/help /language en /priority backlog /good-first-issue </details
/assign

Discussion:
{{% capture overview %}} <del> {{< feature-state state="beta" >}} </del> <ins> {{< feature-state state="beta" for_k8s_version="v1.18" >}} </ins> An increasing number of systems leverage a combination of CPUs and hardware accelerators to support latency-critical execution and high-throughput parallel computation. These include workloads in fields such as telecommunications, scientific computing, machine learning, financial services and data analytics. Such hybrid systems comprise a high performance environment.
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: Line 143, the backquote is placed at wrong position. The flag works with any operation that accepts the flag such as: Line 456~457, it needs to change hugo code for the consistency with other documents Proposed Solution: Line 143: The flag works with any operation that accepts the flag such as: etc. Line 456~457: Learn about . See . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /assign

Discussion:
persistentvolumeclaim/my-pvc created ``` <del> The `--recursive` flag works with any operation that accepts the `--filename,-f` flag such as: `kubectl {create,get,delete,describe,rollout} etc.` </del> <ins> The `--recursive` flag works with any operation that accepts the `--filename,-f` flag such as: `kubectl {create,get,delete,describe,rollout}` etc. </ins> The `--recursive` flag also works when multiple `-f` arguments are provided:

{{% capture whatsnext %}} <del> - [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug-application-cluster/debug-application-introspection/) - [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/) </del> <ins> - Learn about [how to use `kubectl` for application introspection and debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/). - See [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/). </ins> {{% /capture %}}
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. --Need to rectify comment wherein "cluster" is mentioned instead of "user" <!--Required Information--Problem: Comment section reads - Proposed Solution: Comment shall be - "# add a new user to your kubeconf that supports basic auth" Page to Update:
Thanks for spotting this The command you've mentioned lets you tell about new user identity (new to your anyway), including details on how to authenticate as that user. As you say, it doesn't configure etc to know about a new cluster. This looks worth fixing. /help /language en /kind bug /priority important-longterm
/sig cli
Sorry for jumping in, I'm gonna update the Issue labels to reflect the work on linked PR. /remove-help /assign
GitHub didn't allow me to assign the following users: gosoon. 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 : Sorry for jumping in, I'm gonna update the Issue labels to reflect the work on linked PR. /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

Discussion:
kubectl config current-context                       # display the current-context kubectl config use-context my-cluster-name           # set the default context to my-cluster-name <del> # add a new cluster to your kubeconf that supports basic auth </del> <ins> # add a new user to your kubeconf that supports basic auth </ins> kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword # permanently save the namespace for all subsequent kubectl commands in that context.
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 are some broken links in the "Managing your Cluster", "Additional Links" sections. Managing your Cluster section: Line: 336 -This page has gone. I couldn't find any documents about upgrading minikube on macos. This issue was already opened via . Additional Links section: Proposed Solution: Additional Links section: roadmap: (I think the link title should be changed to "Contributing") build guide: adding dependencies guide: (I'm not sure actually...) adding an addon guide: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /assign

Discussion:
## Additional Links <del> * **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://git.k8s.io/minikube/docs/contributors/roadmap.md). * **Development Guide**: See [CONTRIBUTING.md](https://git.k8s.io/minikube/CONTRIBUTING.md) for an overview of how to send pull requests. * **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://git.k8s.io/minikube/docs/contributors/build_guide.md). * **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube, see the [adding dependencies guide](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md). * **Adding a New Addon**: For instructions on how to add a new addon for Minikube, see the [adding an addon guide](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md). </del> <ins> * **Goals and Non-Goals**: For the goals and non-goals of the Minikube project, please see our [roadmap](https://minikube.sigs.k8s.io/docs/contrib/roadmap/). * **Development Guide**: See [Contributing](https://minikube.sigs.k8s.io/docs/contrib/) for an overview of how to send pull requests. * **Building Minikube**: For instructions on how to build/test Minikube from source, see the [build guide](https://minikube.sigs.k8s.io/docs/contrib/building/). * **Adding a New Dependency**: For instructions on how to add a new dependency to Minikube, see the [adding dependencies guide](https://minikube.sigs.k8s.io/docs/contrib/drivers/). * **Adding a New Addon**: For instructions on how to add a new addon for Minikube, see the [adding an addon guide](https://minikube.sigs.k8s.io/docs/contrib/addons/). </ins> * **MicroK8s**: Linux users wishing to avoid running a virtual machine may consider [MicroK8s](https://microk8s.io/) as an alternative. ## Community
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: Powershell markdown code block in block doesn't render correctly Proposed Solution: Move markdown code block out of block or change code block to inline code snippet Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:-- Attached Screenshot of issue !
Duplicate of

Discussion:
{{< /note >}} {{< note >}} <del> If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" ``` in the flannel-host-gw.yml or flannel-overlay.yml file and specify your interface accordingly. </del> <ins> If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") on the Windows nodes, you have to modify the line: ```powershell wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet" ``` in the `flannel-host-gw.yml` or `flannel-overlay.yml` file and specify your interface accordingly. ```bash # Example curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` </ins> {{< /note >}} <del> ```bash # Example curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f - ``` </del> ### Joining a Windows worker node