enhancements
enhancements copied to clipboard
TimeZone support in CronJob
TimeZone support in CronJob
- TimeZone support in CronJob
- Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/3140-TimeZone-support-in-CronJob/README.md
- Discussion Link: https://docs.google.com/document/d/1LZLBGW2wRDwAfdBNHJjFfk9CFoyZPcIYGWU7R1PQ3ng/edit#heading=h.h9p5t69007xy
- Primary contact (assignee): @soltysh
- Responsible SIGs: sig-apps
- Enhancement target (which target equals to which milestone):
- Alpha release target (x.y): 1.24
- Beta release target (x.y): 1.25
- Stable release target (x.y): 1.27
- [x] Alpha
- [x] KEP (
k/enhancements
) update PR(s): https://github.com/kubernetes/enhancements/pull/3143 - [x] Code (
k/k
) update PR(s): https://github.com/kubernetes/kubernetes/pull/108032#discussion_r826164355 - [x] Docs (
k/website
) update PR(s): https://github.com/kubernetes/website/pull/32577
- [x] KEP (
- [x] Beta
- [x] KEP (
k/enhancements
) update PR(s): https://github.com/kubernetes/enhancements/pull/3375 - [x] Code (
k/k
) update PR(s): https://github.com/kubernetes/kubernetes/pull/111435 - [x] Docs (
k/website
) update(s): https://github.com/kubernetes/website/pull/35400
- [x] KEP (
- [ ] Stable
- [ ] KEP (
k/enhancements
) update PR(s): https://github.com/kubernetes/enhancements/pull/3449 - [ ] Code (
k/k
) update PR(s): - [ ] Docs (
k/website
) update(s):
- [ ] KEP (
Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.
/sig apps
Hello @soltysh π, 1.24 Enhancements team here.
Just checking in as we approach enhancements freeze on 18:00pm PT on Thursday Feb 3rd, 2022.
For note, This enhancement is targeting for stage alpha
for 1.24 (correct me, if otherwise)
Hereβs where this enhancement currently stands:
- [x] Updated KEP file using the latest template has been merged into the k/enhancements repo.
- [x] KEP status is marked as
implementable
for this release - [x] KEP has a test plan section filled out.
- [x] KEP has up to date graduation criteria.
- [x] KEP has a production readiness review that has been completed and merged into k/enhancements.
Looks like for this one, we would just require having this KEP PR https://github.com/kubernetes/enhancements/pull/3143 merged & that will mark all the above requirements.
At the moment, the status of this enhancement is marked as at-risk
. Please keep the issue description up-to-date with appropriate stages as well. Thank you!
@Priyankasaggu11929 https://github.com/kubernetes/enhancements/pull/3143 just merged, so I hope that satisfies all the requirements for inclusion.
Thanks! I've moved this to tracked
. All set for enhancement freeze. π
Hi @soltysh ππ» 1.24 Docs shadow here.
This enhancement is marked as 'Needs Docs' for the 1.24 release.
Please follow the steps detailed in the documentation to open a PR against the dev-1.24 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thu March 31, 11:59 PM PDT.
Also, if needed take a look at Documenting for a release to familiarize yourself with the docs requirement for the release.
Thanks!
Hi @soltysh π
Checking in once more as we approach 1.24 code freeze at 01:00 UTC Wednesday 30th March 2022.
Please ensure the following items are completed:
- All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
- All PRs are fully merged by the code freeze deadline.
It looks like we're waiting on this one to merge? -> https://github.com/kubernetes/kubernetes/pull/108032
As always, we are here to help should questions come up.
Thanks!!
It looks like we're waiting on this one to merge? -> kubernetes/kubernetes#108032
correct, that's the only one we need.
docs placeholder opened in https://github.com/kubernetes/website/pull/32577
When we document this, https://github.com/kubernetes/enhancements/pull/3143#discussion_r837782004 strongly suggests to me that we should document how to manage a custom timezone database (via a hostPath
volume mount or similar), and we should do that unless we have a strong commitment from SIG Release about providing official container images for the controller manager that have the timezone data kept very current.
@soltysh Hi! Have you been working on this? If not, I am interested in this feature and I would like to implement it!
@knight42 this merged as alpha in 1.24 see https://github.com/kubernetes/kubernetes/pull/108032 and https://github.com/kubernetes/website/pull/32577 We're planning to promote this further in the next releases.
/milestone clear /tracked no
/milestone v1.25 /stage beta
Hello @soltysh π, 1.25 Enhancements team here.
Just checking in as we approach enhancements freeze on 18:00 PST on Thursday June 16, 2022.
For note, This enhancement is targeting for stage beta
for 1.25 (correct me, if otherwise)
Here's where this enhancement currently stands: (updated on June 9, 2022)
- [ ] KEP file using the latest template has been merged into the k/enhancements repo.
- [X] KEP status is marked as
implementable
- [ ] KEP has a updated detailed test plan section filled out
- [X] KEP has up to date graduation criteria
- [ ] KEP has a production readiness review that has been completed and merged into k/enhancements.
Looks like for this one, we would need to get the open KEP PR https://github.com/kubernetes/enhancements/pull/3375 merged by the Enhancements Freeze.
For note, the status of this enhancement is marked as at risk
. Thank you for keeping the issue description up-to-date!
With KEP PR https://github.com/kubernetes/enhancements/pull/3375 merged, the enhancement is ready for the upcoming enhancements freeze.
For note, the status is now tracked
in the enhancements tracking sheet. Thank you!
Hello @soltysh π, 1.25 Release Docs Lead here. This enhancement is marked as βNeeds Docsβ for 1.25 release.
Please follow the steps detailed in the documentation to open a PR against dev-1.25
branch in the k/website
repo. This PR can be just a placeholder at this time, and must be created by August 4.β¨ Also, take a look at Documenting for a release to familiarize yourself with the docs requirement for the release.
β¨Thank you!
Hi @soltysh π
Checking in once more as we approach 1.25 code freeze at 01:00 UTC on Wednesday, 3rd August 2022.
Please ensure the following items are completed:
- [ ] All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
- [ ] All PRs are fully merged by the code freeze deadline.
I was not able to find any recent k/k PRs related to this KEP. Could you please point me to them, if there are any, OR if you're planning to open any k/k PRs, kindly please link them in the issue. Thank you so much.
The status of this enhancement is marked at at-risk
.
@Priyankasaggu11929 updated description with links to code (https://github.com/kubernetes/kubernetes/pull/111435) and docs (https://github.com/kubernetes/website/pull/35400) changes.
Hey @soltysh π
Checking in once more as we approach 1.25 code freeze at 01:00 UTC on Wednesday, 3rd August 2022, which is tomorrow.
Please ensure that the following PR(s) merged before the code freeze which is in 1 day.
- https://github.com/kubernetes/kubernetes/pull/111435
So, that we can mark this as tracked
.
Thanks
With k/k code PR https://github.com/kubernetes/kubernetes/pull/111435 merged now, this enhancement is marked as tracked
for 1.25 code freeze. Thank you so much @soltysh.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale
- Mark this issue or PR as rotten with
/lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
What is the status of this?
What is the status of this?
https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/3140-TimeZone-support-in-CronJob/kep.yaml provides that info.
/milestone v1.27 /label lead-opted-in /stage stable
Hello @soltysh π, Enhancements team here.
Just checking in as we approach enhancements freeze on 18:00 PDT Thursday 9th February 2023.
This enhancement is targeting for stage stable
for v1.27 (correct me, if otherwise)
Here's where this enhancement currently stands:
- [x] KEP readme using the latest template has been merged into the k/enhancements repo.
- [ ] KEP status is marked as
implementable
forlatest-milestone: v1.27
- [x] KEP readme has a updated detailed test plan section filled out
- [ ] KEP readme has up to date graduation criteria
- [ ] KEP has a production readiness review that has been completed and merged into k/enhancements.
For this enhancement, it looks like https://github.com/kubernetes/enhancements/pull/3449 will address all of the remaining requirements.
The status of this enhancement is marked as at risk
. Please keep the issue description up-to-date with appropriate stages as well.
Thank you!
For this enhancement, it looks like #3449 will address all of the remaining requirements.
correct :)
With #3449 merged this enhancement will be tracked
for v1.27
Thanks!
The implementation of the CronJob API in Kubernetes 1.26 lets you set the
.spec.schedule
field to include a timezone; for example:CRON_TZ=UTC * * * * *
orTZ=UTC * * * * *
.
Do we want to make a stronger statement about this, now that we nearly have GA support for setting a timezone via the API? The other mechanism was never official. This feels like the right time to make it.
For example, we might want to block creates of CronJobs that set a schedule with TZ
/ CRON_TZ
. Possibly behind an on-y-default, disable-if-you-must feature gate?
Do we want to make a stronger statement about this, now that we nearly have GA support for setting a timezone via the API? The other mechanism was never official. This feels like the right time to make it.
I'd wish, but my worry is that we might break users, I'll open a separate PR and let's see if api approvers are willing to accept that.
For example, we might want to block creates of CronJobs that set a schedule with TZ / CRON_TZ. Possibly behind an on-y-default, disable-if-you-must feature gate?
We would need to touch both creates, to ensure new cronjobs are w/o those, and also updates such that you can't add it, if it wasn't already there.