-
Notifications
You must be signed in to change notification settings - Fork 40k
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
ScheduledJob client #25475
ScheduledJob client #25475
Conversation
61fc32d
to
806bb6b
Compare
|
||
func validateScheduleFormat(schedule string, fldPath *field.Path) field.ErrorList { | ||
allErrs := field.ErrorList{} | ||
_, err := cron.Parse(schedule) |
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.
@lavalamp @bgrant0607 is there a limit to how complex of parser we want to include in validation? At some point, is it up to the controller to react to errors in complex fields? In this case, a third-party library is used to parse a cronspec, which is pretty complex. Not a performance issue, I don't think, but maybe a dependency issue.
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.
@soltysh I think adding godep for robfig/cron is fine in this PR. the only thing I am unsure about is whether validation should call Parse, or whether that should be left to the controller to parse, and then raise an event or set a condition if there is an error in the format.
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.
Personally, I'd prefer to know the cron format is wrong at validation and not when the controller will actually try to run it. Although a complex, it's one of those things I'd expect validation to take care.
LGTM. |
@erictune there are a few bit still missing in this PR, but hopefully they will be addressed first thing in the morning. Once that is done I'll work on another PR adding kubectl elements. |
For now I'd like to have the API part to land, there's some release-note-* labeling issue. |
806bb6b
to
812df20
Compare
@erictune this is still not quite finished. The biggest problem with this PR is that until now there was no multi-version client testing framework in place 😢 My approach in the last commit (Enable multi-version tests in client tests) but that needs @caesarxuchao eyes. If this is good enough for now, I'll continue with additional necessary changes to finish it. ptal I need to step away for a few hours, but I'll be online later and I'll try to reach out to you and @caesarxuchao about it on slack. |
@erictune one more option is to split the testing part into a separate PR (including scheduled jobs, because that needs to be tested only in batch/v2alpha1). IMHO, that would be the best option, since with client part in place we can work in parallel, wdyt? |
812df20
to
e4cfe38
Compare
|
|
e4cfe38
to
a5615ee
Compare
@erictune yup, I'm just updating. |
08626bf
to
85ecc00
Compare
Rebased and regenerated. @erictune mind re-applying the label? |
Why aren't scheduled jobs a third party resource and external controller? |
@philips we got a lot of questions about that functionality and after talking with everyone involved we agreed it's one of those features that should be part of the core of the system. |
@soltysh Do you have a link to that discussion? I don't see it on the proposal #11980 and the proposal itself doesn't mention it afaics https://github.com/soltysh/kubernetes/blob/10de4c2d51d14c1efa9ae1f9914136960c081475/docs/proposals/scheduledjob.md I am just searching for "third" so probably just missing it. |
@philips the discussion was held over several issues both k8s and openshift, you'll need to follow the links from initial comments. But generally it all started from a proposal for ScheduledJobs, actually. From that point the current Jobs arose and ScheduledJobs is just a continuation of the topic (see #11746). |
@soltysh OK, could you perhaps summarize in a few sentences what about this wouldn't fit in the third party resource model? We have done TPM support and a number of prototypes on top of third party and I would love to understand how we avoid adding more and more types over time to the core API. Not urgent so I will make a note to ping everyone post v1.3 code freeze. |
@soltysh The main thing in the back of my mind is that expression of time in cron format is potentially a step back. For example systemd timers[1] introduced a number of different ways of expressing time that users may want and that aren't captured in the ScheduledJob
[1] https://wiki.archlinux.org/index.php/Systemd/Timers#Timer_units |
@philips the schedule format was initially influenced by https://github.com/mesos/chronos, we thought about using ISO8601 but after some investigation I've realized it's too limiting and we went with the cron as being the most popular. I don't see any problems with supporting multiple schedule formats with it. Thankfully ScheduledJob is still alpha feature so we're able to make some significant changes to the API based on users and our self's feedback |
Regarding format:
Regarding ThirdParty status: If @Solysh an I can get it done, this is going to be Alpha in 1.3 due to momentum. From there, I had assumed it would go to Beta. But I guess another option could be to decide to move from alpha to third-party. We are going to discuss criteria for something being third-party at a future community meeting (@sarahnovotny is trying to pick a date). That would be a good time to bring up the idea of ScheduledJob being ThirdParty. If someone were to produce a third-party version of scheduledJob, well before 1.4, and show that was comparably useful, that would be persuasive argument for the latter path. I have been thinking about this path while working on the controller. My impression is that it is going to be harder than some people think. But definitely worth trying, so we can improve thirdParty. Interested in hearing what your experience has been working with third party. |
@erictune Sounds great. I will make a note to follow-up with you in a few weeks about what makes schedule jobs hard to do in third party. |
85ecc00
to
6510eb5
Compare
Reapplying lgtm label after rebase. |
GCE e2e build/test passed for commit 6510eb5. |
Automatic merge from submit-queue |
Automatic merge from submit-queue Scheduledjob storage This builds on top of #25475 so only last commit is significant. There's still one small problem with conversions, I'm currently working, but the biggest is still multi-version client tests. Read on... @erictune unfortunately the multi-version tests are biting again, this time in `pkg/registry/scheduledjob/etcd`. If I run the tests with just `batch/v2alpha1` then these are working correctly, but we can't have only `batch/v2alpha1` enabled since `batch/v1` is the preferred version for the entire `batch/` group. We either going to skip the tests here like we did with the scheduledjob client (I'm talking about `pkg/registry/scheduledjob/etcd/etcd_test.go`) or fix it. I've talked with @deads2k about how we can plumb the tests so it just passes, but there's no simple solution we can come up with 😞 (other than the one from #25566), unless @caesarxuchao can chime in and propose something. ```release-note Introducing ScheduledJobs as described in [the proposal](https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/scheduledjob.md) as part of `batch/v2alpha1` version (experimental feature). ``` [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/.github/PULL_REQUEST_TEMPLATE.md?pixel)]()
@erictune SheduledJob part 2, based on #24970 so first two commits doesn't count.
This is still WIP, but it's here so you know :)