Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KEP 3140: TimeZone support for CronJob #108032

Merged
merged 4 commits into from
Mar 30, 2022

Conversation

rosspeoples
Copy link

@rosspeoples rosspeoples commented Feb 9, 2022

What type of PR is this?

/kind feature
/kind api-change

What this PR does / why we need it:

This adds optional support for time zones to CronJobs

Which issue(s) this PR fixes:

Fixes # https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/3140-TimeZone-support-in-CronJob/README.md

Special notes for your reviewer:

Does this PR introduce a user-facing change?

This adds an optional `timeZone` field as part of the CronJob spec to support running cron jobs in a specific time zone.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. kind/feature Categorizes issue or PR as related to a new feature. labels Feb 9, 2022
@k8s-ci-robot
Copy link
Contributor

@deejross: The label(s) kind/api-chainge cannot be applied, because the repository doesn't have them.

In response to this:

What type of PR is this?

/kind feature
/kind api-chainge

What this PR does / why we need it:

This adds optional support for time zones to CronJobs

Which issue(s) this PR fixes:

Fixes # https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/3140-TimeZone-support-in-CronJob/README.md

Special notes for your reviewer:

Does this PR introduce a user-facing change?

This adds an optional `timeZone` field as part of the CronJob spec to support running cron jobs in a specific time zone.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@k8s-ci-robot k8s-ci-robot added do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Feb 9, 2022
@k8s-ci-robot
Copy link
Contributor

Hi @deejross. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@k8s-ci-robot k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Feb 9, 2022
@rosspeoples
Copy link
Author

/assign @soltysh

@k8s-ci-robot k8s-ci-robot added the kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API label Feb 9, 2022
@k8s-ci-robot k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/apps Categorizes an issue or PR as relevant to SIG Apps. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Feb 9, 2022
@k8s-triage-robot
Copy link

This PR may require API review.

If so, when the changes are ready, complete the pre-review checklist and request an API review.

Status of requested reviews is tracked in the API Review project.

pkg/apis/batch/types.go Outdated Show resolved Hide resolved
@soltysh
Copy link
Contributor

soltysh commented Feb 10, 2022

/ok-to-test

@k8s-ci-robot k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Feb 10, 2022
@fedebongio
Copy link
Contributor

We triaged this one, feels it's mostly SIG Apps.
/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Feb 10, 2022
Copy link
Contributor

@ravisantoshgudimetla ravisantoshgudimetla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor style issues but mostly ok. Thank you for the pr @deejross. Please address them. You also need to generate proto and open-api spec. Can you run them and let us know?

pkg/apis/batch/validation/validation.go Outdated Show resolved Hide resolved
pkg/apis/batch/types.go Outdated Show resolved Hide resolved
pkg/controller/cronjob/cronjob_controllerv2.go Outdated Show resolved Hide resolved
pkg/controller/cronjob/cronjob_controllerv2.go Outdated Show resolved Hide resolved
Copy link
Contributor

@soltysh soltysh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/priority important-longterm

pkg/apis/batch/types.go Outdated Show resolved Hide resolved
pkg/apis/batch/types.go Outdated Show resolved Hide resolved
pkg/apis/batch/validation/validation.go Outdated Show resolved Hide resolved
pkg/controller/cronjob/cronjob_controllerv2.go Outdated Show resolved Hide resolved
pkg/controller/cronjob/cronjob_controllerv2.go Outdated Show resolved Hide resolved
@rosspeoples rosspeoples force-pushed the kep3140-cronjob-timezone branch from 8370313 to 37ccd1f Compare March 28, 2022 21:33
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/contains-merge-commits Indicates a PR which contains merge commits. label Mar 28, 2022
@rosspeoples rosspeoples force-pushed the kep3140-cronjob-timezone branch from 37ccd1f to a750962 Compare March 28, 2022 22:46
@rosspeoples
Copy link
Author

/retest

@liggitt
Copy link
Member

liggitt commented Mar 29, 2022

test failure looks related:

k8s.io/kubernetes/pkg/controller/cronjob: TestControllerV2SyncCronJob/never_ran,_not_valid_time_zone expand_less	0s
{Failed  === RUN   TestControllerV2SyncCronJob/never_ran,_not_valid_time_zone
    cronjob_controllerv2_test.go:1051: never ran, not valid time zone: expected 0 event, actually 1
    cronjob_controllerv2_test.go:1062: never ran, not valid time zone: expected 0 warnings, actually 1
    --- FAIL: TestControllerV2SyncCronJob/never_ran,_not_valid_time_zone (0.00s)

@soltysh
Copy link
Contributor

soltysh commented Mar 29, 2022

Yup, it looks like your new test here https://github.com/kubernetes/kubernetes/pull/108032/files#diff-6b48a7bb6b4f570f1f2b46f0ad7e4952f1f8aff5a54b42094a0f1f1bcb216981R244 should expect 1, not 0 since you're passing invalid time zone.

@rosspeoples rosspeoples force-pushed the kep3140-cronjob-timezone branch from a750962 to 32ac89e Compare March 29, 2022 13:11
@soltysh
Copy link
Contributor

soltysh commented Mar 29, 2022

CI failures related with boskos failed to acquire project.
/test pull-kubernetes-node-e2e-containerd
/test pull-kubernetes-e2e-gce-ubuntu-containerd
/test pull-kubernetes-e2e-gce-100-performance

@liggitt
Copy link
Member

liggitt commented Mar 29, 2022

/approve
API changes lgtm

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deejross, liggitt, soltysh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 29, 2022
@rosspeoples rosspeoples force-pushed the kep3140-cronjob-timezone branch from 32ac89e to d26e6cc Compare March 29, 2022 16:41
@soltysh
Copy link
Contributor

soltysh commented Mar 29, 2022

/lgtm
/milestone v1.24

@k8s-ci-robot k8s-ci-robot added this to the v1.24 milestone Mar 29, 2022
@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Mar 29, 2022
@@ -20,6 +20,7 @@ package main

import (
"os"
_ "time/tzdata" // for timeZone support in CronJob
Copy link
Member

@BenTheElder BenTheElder Mar 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only <500kb, but I want to note that we're likely not using this copy anyhow, since the images we publish will have tzdata in them (and .. pretty much any docker base image short of literal FROM SCRATCH) and if the binary is run directly on the host (which seems unusual) host environments generally will as well.

Note from package docs:

Package tzdata provides an embedded copy of the timezone database. If this package is imported anywhere in the program, then if the time package cannot find tzdata files on the system, it will use this embedded information

xref: kubernetes/enhancements#3143 (comment)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's true that it will probably import the tzdata from the image, but I think it's also important to spell out dependencies when possible. Also, I've had trouble in the past with Alpine and other minimal images not including that data and ultimately breaking things.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's true that it will probably import the tzdata from the image, but I think it's also important to spell out dependencies when possible.

It's not clear to me that embedded tzdata is a real dependency that we desire, it will increase the size of our images (granted not drastically) for zero gain since all of our base images contain tzdata, even "distroless", AFAICT there is no scenario in the entire Kubernetes organization + subprojects where this data will actually be used.

Also, I've had trouble in the past with Alpine and other minimal images not including that data and ultimately breaking things.

Yes, but we don't ship alpine based images in Kubernetes, and anyone doing their own custom images is liable to break via failing to include any number of packages already (e.g. cacerts) and should probably just install tzdata.

Copy link
Member

@BenTheElder BenTheElder Mar 29, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also means we have another place where Kubernetes should be trying to keep tzdata patched in the releases we ship, I'm not sure this is desirable vs just using tzdata from the docker images, not to mention [tzdata in the images] being decoupled from go version lifecycle [vs this is not] ... 🤔

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd really like to get this PR in before the 1.24 freeze, and if we want to remove this import (which I'm fine with if we're confident we don't need it), then I can open a separate PR after this one gets merged to remove it, if that's ok.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(if we want to put it in a build-flag gated file so someone can exclude it if they know they don't need it, I wouldn't object to that)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct what Jordan wrote above, last time we discussed and rejected further implementation of this feature was because we did not want to force users to install tzdata explicitly. Having this mechanism as a fallback is what allowed us to proceed. This was explicitly laid out in the motivation section of the KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/3140-TimeZone-support-in-CronJob#motivation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Further more, since this tzdata is embedded inside golang, every time we patch golang we get appropriate patches with it, so I'm not worried about it, since it does not require separate release cadence. Also, as you mentioned the 500kb barely makes a difference in the size of 100MB+ binaries such as kube-apisever and kube-controller-manager.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Golang patch releases do not necessarily happen when the tzdb updates, and go releases are not supported with new patches after some time so users depending on this will be on their own.

I still think it would be reasonable to require tzdb to run the apiserver binaries we ship anyhow, we don't even test it without running in our images which contain it and we require other reasonable system packages to function.

If we make the expectations clear that this will not receive special patching vs regular golang upgrade cadence, I think it is reasonable though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this deserves a build flag for exclusion fwiw. I just don't want any expectation that outdated bundled tzdata will lead to urgent golang updates + k8s releases and I don't see this spelled out anywhere. If we didn't provide the fallback the stance is clearer that users are responsible for having an updated tzdb in their local install. I also don't think we exercise this fallback in CI FWIW though we can probably trust golang there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/apiserver area/code-generation cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/apps Categorizes an issue or PR as relevant to SIG Apps. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
Status: API review completed, 1.24
Development

Successfully merging this pull request may close these issues.

9 participants