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

Add user-friendly cron editor to Rollup Job Wizard #23384

Merged
merged 12 commits into from
Sep 25, 2018

Conversation

cjcenizal
Copy link
Contributor

@cjcenizal cjcenizal commented Sep 21, 2018

Todo:

  • Fix bug where moving forward a step and then back to logistics results in the cron editor being reset
  • Rename "Interval" label to "Frequency"
  • Do test to see what happens when a cron is saved that doesn't make sense, e.g. yearly on Sept 31st. Looks like the API is rejecting date values greater than 23.

image

image

- 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.
@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

Copy link
Contributor

@jen-huang jen-huang left a 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',
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we should have a default delay value, since delay is optional and sounds like it won't be needed for most use cases

similarly, if there is no delay value, it shouldn't be sent with the payload:

image

Copy link
Contributor Author

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.

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.

Copy link
Contributor Author

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 @@
/*
Copy link
Contributor

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!

Copy link
Contributor Author

@cjcenizal cjcenizal Sep 25, 2018

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.

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();
Copy link
Contributor

Choose a reason for hiding this comment

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

is this line needed?

Copy link
Contributor Author

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) {
Copy link
Contributor

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

Copy link
Contributor Author

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.

@cjcenizal
Copy link
Contributor Author

@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.

@cjcenizal cjcenizal merged commit 199c875 into elastic:feature/rollups Sep 25, 2018
@cjcenizal cjcenizal deleted the rollups-cron-editor branch September 25, 2018 02:47
@elasticmachine
Copy link
Contributor

💔 Build Failed

cjcenizal added a commit that referenced this pull request Sep 28, 2018
* 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.
cjcenizal added a commit that referenced this pull request Oct 2, 2018
* 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.
cjcenizal added a commit that referenced this pull request Oct 4, 2018
* 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.
jen-huang pushed a commit that referenced this pull request Oct 17, 2018
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants