-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add user-friendly cron editor to Rollup Job Wizard #23384
Add user-friendly cron editor to Rollup Job Wizard #23384
Conversation
…nd restore the simple editor values.
- Move timezone up into date histogram area. - Move delay into "Schedule" section and add "1d" as the default value. - Update copy to describe how delay is used to adjust for ingest latency issues. - Remove ms and y examples, since they won't be very useful.
💔 Build Failed |
💔 Build Failed |
💔 Build Failed |
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.
This wizard is looking sooooo gooood!! I found the cron editor really intuitive to use. Great job ingesting all that cron syntax information and especially baking in localization from the get-go.
I have a few comments but nothing that blocks the functionality, so feel free to address them with this PR or the next pass.
LGTM!
rollupPageSize: '', | ||
rollupDelay: '1d', |
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.
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.
Good catch on not sending an empty default! Will fix.
I think it was @eskibars who recommended 1d
as a good common default. I'll add a comment to explain this. Shane correct me if I'm wrong, but I believe you said this default would be useful for new users who aren't sure about the kind of ingest latency they'll be encountering.
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.
I did. It is optional and while it may not be needed for many cases, I think 1d may be practical. Basically, if everything is working smoothly (e.g. nobody's restarted a server that's running a filebeat process), then data should more or less com in on time and we wouldn't need a delay. But I think in many real-world cases, servers will go down for a few hours as they're being restarted. 1d would allow them that period to come back up and the "expense" is pretty negligible in most cases: 1 day of extra non-rolled-up data.
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.
Perfect! Thanks for the clarification.
@@ -0,0 +1,362 @@ | |||
/* |
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.
this is such a cool component! 😍 I can totally see this potentially being reused if we have a need for cron configuration via UI elsewhere!
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.
Thanks! Doesn't Watcher use cron as part of its config? I'm guessing it does since the cron info comes from the Watcher docs. Maybe we can reuse this within the Watcher UI.
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.
I just saw this. Yes, Watcher does use cron. I suspect we'll have other components that will want this type of scheduled task config as well.
// Restore the last value of the simple cron editor. | ||
rollupCron: simpleRollupCron, | ||
}); | ||
// hideAdvancedCron(); |
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.
is this line needed?
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.
Ha no, will delete.
import { CronMonthly } from './cron_monthly'; | ||
import { CronYearly } from './cron_yearly'; | ||
|
||
function makeSequence(min, max) { |
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.
this seems somewhat inefficient since the ranges and subsequent values created from this loop are all fixed and will not change over time. I'm not completely sure how to do away with this so I'm adding this comment to open discussion.
could the MINUTE_OPTIONS
and HOUR_OPTIONS
be hardcoded constants (in another file)?
could DAY_OPTIONS
and MONTH_OPTIONS
be retrieved from moment? then moment-local can take care of localization
DATE_OPTIONS
is the toughest one. probably can't avoid a [1...31]
loop here but maybe can be localized with moment as well? examples:
moment('1/3', 'M/D').format('Do');
returns 3rd
moment('1/31', 'M/D').format('Do');
returns 31st
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.
I think you have a good point. I think I'd prefer to just hardcode everything in a constants file and avoid a dependency on moment if we can avoid it.
@jen-huang I started making changes to the date stuff but it seemed to be adding complexity rather than removing it. I think it makes sense to keep it as-is because the code is clear and flexible in its current form, and I don't think it costs too much CPU to make these calculations unaffordable. That said I'm definitely still open to change it at any point down the road. |
💔 Build Failed |
* Add simple CronEditor. * Change label from Interval to Frequency. * Update cron logic to include a year field. * Fix bug in cron format, which incorrectly started with minutes instead of seconds. * Remove Data Source section. - Move timezone up into date histogram area. - Move delay into "Schedule" section and add "1d" as the default value. - Update copy to describe how delay is used to adjust for ingest latency issues. - Remove ms and y examples, since they won't be very useful.
* Add simple CronEditor. * Change label from Interval to Frequency. * Update cron logic to include a year field. * Fix bug in cron format, which incorrectly started with minutes instead of seconds. * Remove Data Source section. - Move timezone up into date histogram area. - Move delay into "Schedule" section and add "1d" as the default value. - Update copy to describe how delay is used to adjust for ingest latency issues. - Remove ms and y examples, since they won't be very useful.
* Add simple CronEditor. * Change label from Interval to Frequency. * Update cron logic to include a year field. * Fix bug in cron format, which incorrectly started with minutes instead of seconds. * Remove Data Source section. - Move timezone up into date histogram area. - Move delay into "Schedule" section and add "1d" as the default value. - Update copy to describe how delay is used to adjust for ingest latency issues. - Remove ms and y examples, since they won't be very useful.
* Add simple CronEditor. * Change label from Interval to Frequency. * Update cron logic to include a year field. * Fix bug in cron format, which incorrectly started with minutes instead of seconds. * Remove Data Source section. - Move timezone up into date histogram area. - Move delay into "Schedule" section and add "1d" as the default value. - Update copy to describe how delay is used to adjust for ingest latency issues. - Remove ms and y examples, since they won't be very useful.
Todo: