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: Deployment yaml file: mysql- api version does not fit 1.9 version: apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment Proposed Solution: change apiVersion to: apps/v1 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 9 ! <!--Additional Information:--

Discussion:
<del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: patch-demo

<del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: nginx-deployment

requests: storage: 20Gi --- <del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: mysql

requests: storage: 20Gi --- <del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: wordpress-mysql

requests: storage: 20Gi --- <del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: wordpress

<del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: frontend

<del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: redis-master

<del> apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1 </del> <ins> apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 </ins> kind: Deployment metadata: name: redis-slave
Change:
[X] Feature Request Problem: When upstream master removed an API that the docs tests check, all travis builds started failing. The immediate issue is fixed in two ways, with : changed the API checks that failed changed the upstream version from master to latest stable release This is an excellent interim solution, but we need to do a few more things to ensure that such breaks don't happen again. Proposed Solution: document for docs release meister that when release is cut, tests should be updated to run against the latest release versiondocument for docs release meister or shadow or other that we should check for any API changes that could break the tests. We can check the release notes manually for now, and devise an automated solution if the manual approach proves inadequate or someone wants to get clever. (Note that checking the API refdocs is not a reliable solution here. example: the 1.10 refdocs are wrong for exactly the offending API in the test break.) Page to Update:
Thank you for this--I'll take it on for my playbook update in
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

Discussion:
Edit the yaml files in `/_data/` for the Guides, Reference, Samples, or Support areas. <ins> You may have to exit and `jekyll clean` before restarting the `jekyll serve` to get changes to files in `/_data/` to show up. </ins> ### Add Images Put the new image in `/images/docs/` if it's for the documentation, and just `/images/` if it's for the website.
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [ X] Bug Report Problem: SSH Tunneling link is broken Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--

Discussion:
provide the apiserver with a root certificate bundle to use to verify the kubelet's serving certificate. <del> If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) </del> <ins> If that is not possible, use [SSH tunneling](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) </ins> between the apiserver and kubelet if required to avoid connecting over an untrusted or public network.
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [ ] Bug Report Problem: api doc reference not working properly due to jquery- and not found. 404 (Not Found) 404 (Not Found) Proposed Solution: put back the missing JS file Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--11 12 13 <!--Additional Information:--
12 works. 1.11 and 1.13 doesn't work.

Discussion:
</TABLE> </DIV> </DIV> <del> <SCRIPT src="/js/jquery-2.2.0.min.js"></SCRIPT> </del> <ins> <SCRIPT src="/js/jquery-3.2.1.min.js"></SCRIPT> </ins> <SCRIPT src="jquery.scrollTo.min.js"></SCRIPT> <del> <SCRIPT src="/js/bootstrap.min.js"></SCRIPT> </del> <ins> <SCRIPT src="/js/bootstrap-3.3.7.min.js"></SCRIPT> </ins> <SCRIPT src="navData.js"></SCRIPT> <SCRIPT src="scroll.js"></SCRIPT> </BODY>
Change:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: The last table after the paragraph shows that pod-b available, which I think that it's wrong, because previously it says "It will succeed at evicting pod-b" Proposed Solution: pod-b terminating Page to Update:
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
/remove-lifecycle stale
/priority backlog
/kind bug
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
/remove-lifecycle stale
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 rotten
/assign

Discussion:
|    node-1 *drained*  |       node-2        |       node-3       | *no node*          | |:--------------------:|:-------------------:|:------------------:|:------------------:| <del> |                      | pod-b *available*   | pod-c *available*  | pod-e *pending*    | </del> <ins> |                      | pod-b *terminating* | pod-c *available*  | pod-e *pending*    | </ins> |                      | pod-d *available*   | pod-y              |                    | At this point, the cluster administrator needs to
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: This is the first one you get when searching docs for CronJob. I know this is a small suggestion but i think it would help a lot in reducing time searching / exploring kubectl explain. Proposed Solution: It should imho contain a example just like on the page: this would help to speed up search if needed fast. This example one: (copy paste from url) Page to Update:
This is similar to issue

Discussion:
{{< feature-state for_k8s_version="v1.8" state="beta" >}} <del> A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) on a time-based schedule. </del> <ins> A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repeating schedule. </ins> One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.

append 11 characters to the job name provided and there is a constraint that the maximum length of a Job name is no more than 63 characters. <del> For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). </del> {{% /capture %}} <ins> {{% capture body %}} ## CronJob </ins> <del> {{% capture body %}} </del> <ins> CronJobs are useful for creating periodic and recurring tasks, like running backups or sending emails. CronJobs can also schedule individual tasks for a specific time, such as scheduling a Job for when your cluster is likely to be idle. ### Example This example CronJob manifest prints the current time and a hello message every minute: {{< codenew file="application/job/cronjob.yaml" >}} </ins> <del> ## Cron Job Limitations </del> <ins> ([Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/) takes you through this example in more detail). ## CronJob limitations {#cron-job-limitations} </ins> A cron job creates a job object _about_ once per execution time of its schedule. We say "about" because there are certain circumstances where two jobs might be created, or no job might be created. We attempt to make these rare,

the Job in turn is responsible for the management of the Pods it represents. {{% /capture %}} <ins> {{% capture whatsnext %}} [Cron expression format](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format) documents the format of CronJob `schedule` fields. For instructions on creating and working with cron jobs, and for an example of CronJob manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). {{% /capture %}} </ins>
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: is used but it has already been deprecated and this is v1 section. ! Proposed Solution: It should be replaced with . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--

Discussion:
### kubelet [kubelet](/docs/admin/kubelet) is the primary node agent. It: * Watches for pods that have been assigned to its node (either by apiserver or via local configuration file) and: <del> * Mounts the pod's required volumes * Downloads the pod's secrets * Run the pod's containers via docker (or, experimentally, rkt). * Periodically executes any requested container liveness probes. * Reports the status of the pod back to the rest of the system, by creating a "mirror pod" if necessary. </del> <ins> * Mounts the pod's required volumes * Downloads the pod's secrets * Run the pod's containers via docker (or, experimentally, rkt). * Periodically executes any requested container liveness probes. * Reports the status of the pod back to the rest of the system, by creating a "mirror pod" if necessary. </ins> * Reports the status of the node back to the rest of the system. ### kube-proxy
Change:
It seems that this note is inaccurate by saying it's based on timezone. In fact messaging is alluding that timezone will not be supported and it's based on UTC.
Here's the change for posterity.
Thanks for reporting this /kind bug /priority important-longterm /good-first-issue
/assign
Hello Team Is there any deadline when this issue will be fixed ? can we get the the Timezone functionality also with thes CronJob Just want to know
Kubernetes is an open-source, volunteer led project. There aren't deadlines per se. If you're keen to see the documentation changed, for this or any issue, anyone can .
(If anyone would like to help here but is not sure how to get started, please reply&mdash;advice is available).
The change is wrong, the time IS taken from the master node the controller is running on, or from within the container controller-manager is running. It's not hardcoded to be UTC. Why are you claiming otherwise, have you checked?
Ah, so this issue is invalid and needs reverting?
(alternative fix: revert, then revise so that all times are_ in UTC)
I looked at the code: and it looks to me that this issue is invalid. I propose to close it if there's no update in the next fortnight. /remove-good-first-issue /remove-help /remove-kind bug /remove-priority important-longterm
Is this issue not valid ? , In our instance , we have 2 master node and it configured as EST timezone and 4 worker node and configured as EST timezone , but still cron job runs on the UTC Timezone
Is the advice at https://deploy-preview---kubernetes-io-master- accurate?
Okay thanks!! Now document looks aligned thanks we can close!!

Discussion:
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format. <del> {{< note >}} All **CronJob** `schedule:` times are denoted in UTC. {{< /note >}} </del> <ins> {{< caution >}} All **CronJob** `schedule:` times are based on the timezone of the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}. If your control plane runs the kube-controller-manager in Pods or bare containers, the timezone set for the kube-controller-manager container determines the timezone that the cron job controller uses. {{< /caution >}} </ins> When creating the manifest for a CronJob resource, make sure the name you provide is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
Change:
This is an enhancement 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 I'd like to use monospace () text for the paths in the two rightmost columns in the table: HostFolder VM Why is this needed Improved styling. It's a minor thing that's nice to have. Comments /kind cleanup /language en
/assign
If anyone would like to work on this, please feel free to open a pull request.
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 rotten /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 : /remove-lifecycle rotten /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
Hey I would like to work on this.
Anyone who'd like to open a PR that addresses this issue is welcome to. Dive in!
I am working on this, will submit a PR shortly.

Discussion:
| Driver | OS | HostFolder | VM | | --- | --- | --- | --- | <del> | VirtualBox | Linux | /home | /hosthome | | VirtualBox | macOS | /Users | /Users | | VirtualBox | Windows | C://Users | /c/Users | | VMware Fusion | macOS | /Users | /mnt/hgfs/Users | | Xhyve | macOS | /Users | /Users | </del> <ins> | VirtualBox | Linux | `/home` | `/hosthome` | | VirtualBox | macOS | `/Users` | `/Users` | | VirtualBox | Windows | `C://Users` | `/c/Users` | | VMware Fusion | macOS | `/Users` | `/mnt/hgfs/Users` | | Xhyve | macOS | `/Users` | `/Users` | </ins> ## Private Container Registries
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: Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
could you provide some more information about what isn't right with
Tim, I am getting this !
I think you're concerned about the deprecation warning Have I got that right? /triage needs-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
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
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
/reopen
/assign
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

Discussion:
a Hello world application by entering this command: ```shell <del> kubectl run node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 </del> <ins> kubectl create deployment node-hello --image=gcr.io/google-samples/node-hello:1.0 --port=8080 </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. --We have setup the Kuberntes cluster in our Environment we have 2 master node and 4 worker node which all installed EST Time zone Cron Job is scheduled at 12:01 daily midnight And Job is started on 19:01 EST Time instead of 12:01 Time , I feel this running as UTC Timezone <!--Required Information--Problem: The cron Job is not running on the timezone of the master node its running on the UTC Timezone ie OS layer of your Docker image Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--v1.13.1 <!--Additional Information:--
It looks like this is a duplicate of issue

Discussion:
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format. <del> {{< note >}} All **CronJob** `schedule:` times are denoted in UTC. {{< /note >}} </del> <ins> {{< caution >}} All **CronJob** `schedule:` times are based on the timezone of the {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}. If your control plane runs the kube-controller-manager in Pods or bare containers, the timezone set for the kube-controller-manager container determines the timezone that the cron job controller uses. {{< /caution >}} </ins> When creating the manifest for a CronJob resource, make sure the name you provide is a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).