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

[7.x Backport] Force selection of calendar or fixed intervals #41906

Merged
merged 9 commits into from
May 20, 2019

Conversation

polyfractal
Copy link
Contributor

Backport of #33727

Putting up for some CI cycles since there are some yaml tests that needed tweaking for 7.x

polyfractal and others added 2 commits May 6, 2019 17:23
…stic#33727)

The date_histogram accepts an interval which can be either a calendar
interval (DST-aware, leap seconds, arbitrary length of months, etc) or
fixed interval (strict multiples of SI units). Unfortunately this is inferred
by first trying to parse as a calendar interval, then falling back to fixed
if that fails.

This leads to confusing arrangement where `1d` == calendar, but
`2d` == fixed.  And if you want a day of fixed time, you have to
specify `24h` (e.g. the next smallest unit).  This arrangement is very
error-prone for users.

This PR adds `calendar_interval` and `fixed_interval` parameters to any
code that uses intervals (date_histogram, rollup, composite, datafeed, etc).
Calendar only accepts calendar intervals, fixed accepts any combination of
units (meaning `1d` can be used to specify `24h` in fixed time), and both
are mutually exclusive.

The old interval behavior is deprecated and will throw a deprecation warning.
It is also mutually exclusive with the two new parameters. In the future the
old dual-purpose interval will be removed.

The change applies to both REST and java clients.
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo

@spalger
Copy link
Contributor

spalger commented May 8, 2019

FYI @elastic/es-ui, when this goes in elastic/kibana#36269 will start failing on 7.x

Due to the fallthrough logic, DateIntervalWrapper assumed that an
otherwise unparsable interval was a legacy fixed millis interval. This
could then NPE if the interval was just illegal ("foobar").

This commit correctly checks if the legacy millis parsing fails too,
and throws an IllegalArgumentException at that point signaling the
provided interval is bad.
The Max Bucket test can potentially return a partial response,
where one of the shards suceeds but another fails due to the max_bucket
setting.  In the case of a partial failure, the status code is 200 OK
since some results were returned (with failures listed in the body).

This makes the yaml test fail since it is expecting a 4xx/5xx failure
when catching exception messages.

We need to disallow partial results so that the entire query fails
and we can check for the max_bucket failure.
Original PR missed documentation for the new calendar/fixed
intervals.  This adds the missing documentation
@polyfractal polyfractal merged commit 6ae6f57 into elastic:7.x May 20, 2019
jkakavas added a commit that referenced this pull request May 21, 2019
polyfractal added a commit to polyfractal/elasticsearch that referenced this pull request May 21, 2019
After elastic#41906 was
backported, we need to update the various test skips and version
constants
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request May 21, 2019
…der-permit-primary-mode-only

* elastic/master:
  Move the FIPS configuration back to the build plugin (elastic#41989)
  Remove stray back tick that's messing up table format (elastic#41705)
  Add missing comma in code section (elastic#41678)
  add 7.1.1 and 6.8.1 versions (elastic#42253)
  Use spearate testkit dir for each run (elastic#42013)
  Add experimental and warnings to vector functions (elastic#42205)
  Fix version in tests since elastic#41906 was merged
  Bump version in BWC check after backport
  Prevent in-place downgrades and invalid upgrades (elastic#41731)
  Mute date_histo interval bwc test
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request May 21, 2019
* master: (176 commits)
  Avoid unnecessary persistence of retention leases (elastic#42299)
  [ML][TEST] Fix limits in AutodetectMemoryLimitIT (elastic#42279)
  [ML Data Frame] Persist and restore checkpoint and position (elastic#41942)
  mute failing filerealm hash caching tests (elastic#42304)
  Safer Wait for Snapshot Success in ClusterPrivilegeTests (elastic#40943)
  Remove 7.0.2 (elastic#42282)
  Revert "Remove 7.0.2 (elastic#42282)"
  [DOCS] Copied note on slicing support to Slicing section. Closes 26114 (elastic#40426)
  Remove 7.0.2 (elastic#42282)
  Mute all ml_datafeed_crud rolling upgrade tests
  Move the FIPS configuration back to the build plugin (elastic#41989)
  Remove stray back tick that's messing up table format (elastic#41705)
  Add missing comma in code section (elastic#41678)
  add 7.1.1 and 6.8.1 versions (elastic#42253)
  Use spearate testkit dir for each run (elastic#42013)
  Add experimental and warnings to vector functions (elastic#42205)
  Fix version in tests since elastic#41906 was merged
  Bump version in BWC check after backport
  Prevent in-place downgrades and invalid upgrades (elastic#41731)
  Mute date_histo interval bwc test
  ...
polyfractal added a commit that referenced this pull request May 22, 2019
After #41906 was
backported, we need to update the various test skips and version
constants
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
gurkankaymak pushed a commit to gurkankaymak/elasticsearch that referenced this pull request May 27, 2019
After elastic#41906 was
backported, we need to update the various test skips and version
constants
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants