jiebi/CodeConvo huggingface dataset:
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The link in is broken Proposed Solution: Fix the link Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
/assign That patch is a more complete one.
GitHub didn't allow me to assign the following users: kairen. Note that only can be assigned. <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

Discussion:
3. allows connections to TCP port 6379 of "role=db" pods in the "default" namespace from any pod in a namespace with the label "project=myproject" 3. allows connections from any pod in the "default" namespace with the label "role=db" to CIDR 10.0.0.0/24 on TCP port 5978 <del> See the [NetworkPolicy getting started guide](/docs/getting-started-guides/network-policy/walkthrough) for further examples. </del> <ins> See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. </ins> ## Default policies
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The documentation states that the MountPropagation=true feature-gate needs to be enabled, but it is unclear where it needs to be set. Kubelet? kube-apiserver? anywhere else? Proposed Solution: Need to document where the flag is useful. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This looks related to . Would you mind taking a look, please?
FYI, I just got it to work. The flag was needed to be applied to the kube-apiserver and kubelet. I did not set the flag on any other services.
IMO, all features should be enabled on all components, otherwise you risk errors. Here it may be enough to enable it on API server and kubelet, but you can't be 100% sure with other features.
I agree, but the bug report was "how do I get the mount propagation feature to work, as the documentation for it was unclear". Having the documentation be updated to be more accurate/specific I think is a good thing.
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign

Discussion:
Mount propagation allows for sharing volumes mounted by a Container to other Containers in the same Pod, or even to other Pods on the same node. <del> If the MountPropagation feature is disabled, volume mounts in pods are not propagated. </del> <ins> If the "`MountPropagation`" feature is disabled, volume mounts in pods are not propagated. </ins> That is, Containers run with `private` mount propagation as described in the [Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt). To enable this feature, specify `MountPropagation=true` in the <del> `--feature-gates` command line option. When enabled, the `volumeMounts` field of a Container has a new `mountPropagation` subfield. Its values are: </del> <ins> `--feature-gates` command line option for the API server and kubelets. When enabled, the `volumeMounts` field of a Container has a new `mountPropagation` subfield. Its values are: </ins> * `HostToContainer` - This volume mount will receive all subsequent mounts that are mounted to this volume or any of its subdirectories. This is
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: At "Cloud Providers" paragraph, There is a sentence following. In this sentence, is "openshift" correct? It should be "openstack", I think. Because following sentence is described at same paragraph. Here, "openshift" isn't present, but "openstack" is present. Proposed Solution: Replace "openshift" with "openstack" in sentence at "Cloud Providers" paragraph following. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
thanks - I suspect you're correct and made a quick patch () to resolve. When I looked in the cloud-provider releases for 1.8, there was one for openstack, but not openshift - so I think this was just a missed typo/reference mistake

Discussion:
Some cloud providers require a config file. If so, you need to put config file into apiserver image or mount through hostPath. - `--cloud-config=` set if cloud provider requires a config file. <del> - Used by `aws`, `gce`, `mesos`, `openshift`, `ovirt` and `rackspace`. </del> <ins> - Used by `aws`, `gce`, `mesos`, `openstack`, `ovirt` and `rackspace`. </ins> - You must put config file into apiserver image or mount through hostPath. - Cloud config file syntax is [Gcfg](https://code.google.com/p/gcfg/). - AWS format defined by type [AWSCloudConfig](https://releases.k8s.io/{{page.githubbranch}}/pkg/cloudprovider/providers/aws/aws.go)
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: When switching to a different version of the docs, I get redirected to the root of the doc tree. Proposed Solution: Would be nice to redirect users to an equivalent page in the previous version of docs. Easy way to get started would be to just support pages that haven't moved or been refactored. Could get fancier after that.
Also related (found while I was reproducing this), the drop-down mechanism that allows version changing doesn't render correctly on safari (mobile or laptop) so that you can't choose the older versions, and the same happens in Chrome (IOS) - you see part of 1.8, but the rest of the list is cut off. See embedded screenshot (from Chrome IOS) !
I've attempted to implement a solution to this in . This part works by default This part requires setting data on the page as to where to send the person.
This issue is still present on the current version of the website.
not sure if we should reopen this issue or file a new one as a bug report but this no longer works. from what I can tell during the migration to hugo the header file was removed

Discussion:
version: "v1.9" githubbranch: "v1.9.0" docsbranch: "release-1.9" <del> url: https://kubernetes.io/docs/home/ </del> <ins> url: https://kubernetes.io </ins> - fullversion: "v1.8.4" version: "v1.8" githubbranch: "v1.8.4" docsbranch: "release-1.8" <del> url: https://v1-8.docs.kubernetes.io/docs/home/ </del> <ins> url: https://v1-8.docs.kubernetes.io </ins> - fullversion: "v1.7.6" version: "v1.7" githubbranch: "v1.7.6" docsbranch: "release-1.7" <del> url: https://v1-7.docs.kubernetes.io/docs/home/ </del> <ins> url: https://v1-7.docs.kubernetes.io </ins> - fullversion: "v1.6.8" version: "v1.6" githubbranch: "v1.6.8" docsbranch: "release-1.6" <del> url: https://v1-6.docs.kubernetes.io/docs/home/ </del> <ins> url: https://v1-6.docs.kubernetes.io </ins> - fullversion: "v1.5.7" version: "v1.5" githubbranch: "v1.5.7" docsbranch: "release-1.5" <del> url: https://v1-5.docs.kubernetes.io/docs/ </del> <ins> url: https://v1-5.docs.kubernetes.io </ins> deprecated: false currentUrl: https://kubernetes.io/docs/home/ nextUrl: http://kubernetes-io-vnext-staging.netlify.com/

</a> <ul> {% for version in page.versions %} <del> <li><a href="{{ version.url }}">{{ version.version }}</a></li> </del> <ins> {% if page.versionedurl contains version.version %} <li><a href="{{ version.url }}{{ page.versionedurl[version.version] }}">{{ version.version }}</a></li> {% else  %} <li><a href="{{ version.url }}{{ page.url }}">{{ version.version }}</a></li> {% endif %} </ins> {% endfor %} </ul> </li>
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: The other day I was informed that when interracting with the Kubernetes Developer Community on slack I should change my Slack display name to be the same as my github handle. The person telling me then wondered if we had this documented in the new developer guide. I checked and this does not appear to be mentioned in the new developer guide. Proposed Solution: Add a section to the new developer guide () to mention that when interracting with the Kubernetes Developer Community on slack all contributors should make sure their Slack display name is the same as their github handle. Page to Update:
Great! I'll add this one to my todo list. Thanks!
It'd also be good to keep the icon the same between GH and slack. I think that's more recognizable. But that's okay, it depends on guys' wish.

Discussion:
1. There is not yet an easy way to generate a `kubeconfig` file which can be used to authenticate to the cluster remotely with `kubectl` on, for example, your workstation. Workaround: copy the kubelet's `kubeconfig` from the master: use `scp root@<master>:/etc/kubernetes/admin.conf .` and then e.g. `kubectl --kubeconfig ./admin.conf get nodes` from your workstation. <ins> 1. If you are using VirtualBox (directly or via Vagrant), you will need to ensure that `hostname -i` returns a routable IP address (i.e. one on the second network interface, not the first one). By default, it doesn't do this and kubelet ends-up using first non-loopback network interface, which is usually NATed. Workaround: Modify `/etc/hosts`, take a look at this [`Vagrantfile`][ubuntu-vagrantfile] for how you this can be achieved. [ubuntu-vagrantfile]: https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11), </ins>
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ X] Feature Request [ ] Bug Report Problem: Some Kubernetes platforms are best described as being an On-Prem Turnkey Solution. This category is not properly mentioned or described on the Picking the Right Solution page ( ) Proposed Solution: Add a new section called On-Prem Turn-key Cloud Solutions right below the existing Turn-key Cloud Solutions section that describes this category and list platforms that fit into this category. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
^
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. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /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-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close

Discussion:
When you are ready to scale up to more machines and higher availability, a [hosted solution](#hosted-solutions) is the easiest to create and maintain. [Turnkey cloud solutions](#turnkey-cloud-solutions) require only a few commands to create <del> and cover a wide range of cloud providers. </del> <ins> and cover a wide range of cloud providers. [On-Premises turnkey cloud solutions](#on-premises-turnkey-cloud-solutions) have the simplicity of the turnkey cloud solution combined with the security of your own private network. </ins> If you already have a way to configure hosting resources, use [kubeadm](/docs/setup/independent/create-cluster-kubeadm/) to easily bring up a cluster with a single command per machine.

* [KUBE2GO.io](https://kube2go.io/) * [Madcore.Ai](https://madcore.ai/) <ins> # On-Premises turnkey cloud solutions These solutions allow you to create Kubernetes clusters on your internal, secure, cloud network with only a few commands. * [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/) </ins> # Custom Solutions Kubernetes can run on a wide range of Cloud providers and bare-metal environments, and with many
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: In the service type: LoadBalancer example configuration, having the field NodePort wouldn't work. Proposed Solution: To remove the NodePort configuration in the example config. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--

Discussion:
- protocol: TCP port: 80 targetPort: 9376 <del> nodePort: 30061 </del> clusterIP: 10.0.171.239 loadBalancerIP: 78.11.24.19 type: LoadBalancer
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The link of kubelet is broken. The directed page gives 404. doesn't redirect to Proposed Solution: It should redirect to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
I will have a look about it

Discussion:
/docs/admin/kube-scheduler/     /docs/reference/generated/kube-scheduler/ 301 /docs/admin/kube-scheduler/     /docs/reference/generated/kube-scheduler/ 301 /docs/admin/kubeadm/     /docs/reference/generated/kubeadm/ 301 <ins> /docs/admin/kubelet/      /docs/reference/generated/kubelet/ 301 </ins> /docs/admin/federation-controller-manager/    /docs/reference/generated/federation-controller-manager/ 301 /docs/admin/federation-apiserver/      /docs/reference/generated/federation-apiserver/ 301 /docs/admin/kubefed/     /docs/reference/generated/kubefed/ 301
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: I encounter this error when running the step on the Hello Minikube tutorial: Proposed Solution: The solution by from a worked for me: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
resolved with

Discussion:
The `--vm-driver=xhyve` flag specifies that you are using Docker for Mac. The default VM driver is VirtualBox. <ins> Note if `minikube start --vm-driver=xhyve` is unsuccessful due to the error: ``` Error creating machine: Error in driver during machine creation: Could not convert the UUID to MAC address: exit status 1 ``` Then the following may resolve the `minikube start --vm-driver=xhyve` issue: ``` rm -rf ~/.minikube sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve ``` </ins> Now set the Minikube context. The context is what determines which cluster `kubectl` is interacting with. You can see all your available contexts in the `~/.kube/config` file.
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x ] Bug Report Problem: Link to kubeadm reference guide broken. In step (2/4) Initializing your master, the link here is broken: "Please refer to the kubeadm reference guide if you want to read ..." Proposed Solution: Page to Update: backed by: docs/setup/independent/create-cluster- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--

Discussion:
**Notes:** <del> - Please refer to the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/) if you want to </del> <ins> - Please refer to the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/kubeadm/) if you want to </ins> read more about the flags `kubeadm init` provides. You can also specify a [configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) instead of using flags. - You need to choose a Pod Network Plugin in the next step. Depending on what
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: Ingress documentation contains a link to a project () that is deprecated. Proposed Solution: Update the link and the docs to point , which lists non-cloud ingress alternatives. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--

Discussion:
### Loadbalancing <del> An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://git.k8s.io/contrib/service-loadbalancer). With time, we plan to distill load balancing patterns that are applicable cross platform into the Ingress resource. </del> <ins> An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others. More advanced load balancing concepts (e.g.: persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can still get these features through the [service loadbalancer](https://github.com/kubernetes/ingress-nginx/blob/master/docs/catalog.md). With time, we plan to distill load balancing patterns that are applicable cross platform into the Ingress resource. </ins> It's also worth noting that even though health checks are not exposed directly through the Ingress, there exist parallel concepts in Kubernetes such as [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/) which allow you to achieve the same end result. Please review the controller specific docs to see how they handle health checks ([nginx](https://git.k8s.io/ingress-nginx/README.md), [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)).
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This reads a little unclear: kube-scheduler kube-scheduler watches newly created pods that have no node assigned, and selects a node for them to run on. Proposed Solution: kube-scheduler kube-scheduler watches for newly created pods that are not assigned to any node, and selects a node for them to run on. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign

Discussion:
### kube-scheduler <del> [kube-scheduler](/docs/admin/kube-scheduler/) watches newly created pods that have no node assigned, and selects a node for them to run on. </del> <ins> [kube-scheduler](/docs/admin/kube-scheduler/) watches newly created pods that are not assigned to any node, and selects a node for them to run on. </ins> ### addons
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This doc refers to deprecated kubelet flag --api-servers Proposed Solution: Use what is preferred now (maybe kubeconfig?) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--1 <!--Additional Information:--
yes, we do not use for kubelet start parameter, and use kubeconfig instead. do you find some outdated pages? you can list here, and we will fix it. Thanks.
Yes, page to update in the subject line Sorry I somehow missed the url field in bug report body.
/assign

Discussion:
Arguments to consider: - If following the HTTPS security approach: <del> - `--api-servers=https://$MASTER_IP` </del> - `--kubeconfig=/var/lib/kubelet/kubeconfig` - Otherwise, if taking the firewall-based security approach <del> - `--api-servers=http://$MASTER_IP` </del> - `--config=/etc/kubernetes/manifests` - `--cluster-dns=` to the address of the DNS server you will setup (see [Starting Cluster Services](#starting-cluster-services).) - `--cluster-domain=` to the dns domain prefix to use for cluster DNS addresses.
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [* ] Bug Report Problem: preStop handler not working when job was deleted Proposed Solution: if issue actually exists along with tests, special statement should be given for documentation Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--9 <!--Additional Information:--
please track this issue: kubernetes/kubernetes At the same time, we should document it.
ok thanks! very expected to proceed it.

Discussion:
unless the Pod's grace period expires. For more details, see [Termination of Pods](/docs/user-guide/pods/#termination-of-pods). <ins> **Note**: Kubernetes only sends the preStop event when a Pod is *terminated*. This means that the preStop hook is not invoked when the Pod is *completed*. This limitation is tracked in [issue #55087](https://github.com/kubernetes/kubernetes/issues/55807). {: .note} </ins> {% endcapture %}