-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
Forbid creating CronJob with TZ or CRON_TZ, but allow updates #116252
Conversation
/hold |
/sig apps |
-Fail CronJob creation with TZ or CRON_TZ set in .spec.schedule
+Fail CronJob creation with TZ or CRON_TZ set in `.spec.schedule` ? We can use Markdown in the changelog. |
We could have an on-by-default feature gate for this, and for one release allow people to force it off (to help people migrate). Even though the “wrong” way was never official. |
should we wait until TimeZone is enabled by default or GA in all supported releases before dropping this? rejecting this now means you can't write a manifest that uses time zone and works with all supported kubernetes versions |
I think that's a reasonable approach. /milestone v1.28 |
I suppose the genie is out of the bottle.
I mean, I guess, but: how much do we want to tacitly endorse |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
827d128
to
a372f36
Compare
@liggitt this should be ready for a re-review, unfortunately I had to leave that mutation tag, since the verification mechanism is rather simple and will always match that line, and I don't want to change the entire method's body just in case someone will in the future try to modify. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/assign @liggitt
for api change review
LGTM label has been added. Git tree hash: cc896e36c026a8542ab074fbe78868f86c4fd278
|
@@ -564,13 +568,16 @@ func validateConcurrencyPolicy(concurrencyPolicy *batch.ConcurrencyPolicy, fldPa | |||
return allErrs | |||
} | |||
|
|||
func validateScheduleFormat(schedule string, timeZone *string, fldPath *field.Path) field.ErrorList { | |||
func validateScheduleFormat(schedule, oldSchedule string, timeZone *string, fldPath *field.Path) field.ErrorList { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rather than passing in the whole schedule, I think it would be easier to understand and unit test to make the parameter here as narrow as possible, like allowTZInSchedule bool
could invoke it like this:
allowTZInSchedule := false
if oldSpec != nil {
allowTZInSchedule = strings.Contains(oldSpec.Schedule, "TZ")
}
allErrs = append(allErrs, validateScheduleFormat(spec.Schedule, allowTZInSchedule, spec.TimeZone, fldPath.Child("schedule"))...)
and use it like this:
switch {
case allowTZInSchedule && strings.Contains(schedule, "TZ") && timeZone != nil:
allErrs = append(allErrs, field.Invalid(fldPath, schedule, "cannot use both timeZone field and TZ or CRON_TZ in schedule"))
case !allowTZInSchedule && strings.Contains(schedule, "TZ"):
allErrs = append(allErrs, field.Invalid(fldPath, schedule, "cannot use TZ or CRON_TZ in schedule, use timeZone field instead"))
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great suggestion - updated.
a372f36
to
9a58f6c
Compare
/uncc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
/kind deprecation
LGTM label has been added. Git tree hash: 9d10a1efab75a10a906f33f8e760d01a56f7fefc
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, pacoxu, 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 |
be sure to open a docs PR to update the https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#unsupported-timezone-specification to say
|
Done in kubernetes/website#43654 |
What type of PR is this?
/kind cleanup
/kind api-change
What this PR does / why we need it:
Back in #106455 (k8s 1.23) after we've upgraded github.com/robfig/cron (in #102735) we've accidentally exposed internal details of the library allowing users to set
TZ
orCRON_TZ
variable in.spec.schedule
to affect TimeZone of a CronJob.Now that kubernetes/enhancements#3140 is becoming GA we're proposing failing creating a new CronJobs with
TZ
orCRON_TZ
in.spec.Schedule
in favor of setting.spec.timeZone
, but leave the warning and allow updates not to break users.Special notes for your reviewer:
/assign @liggitt @sftim
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: