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

[ML-DataFrame] make checkpointing more robust #44344

Merged
merged 5 commits into from
Jul 16, 2019

Conversation

hendrikmuhs
Copy link

make checkpointing more robust:

  • do not let checkpointing fail if indexes got deleted
  • treat missing seqNoStats as just created indices (checkpoint 0)
  • loglevel: do not treat failed updated checks as error

fixes #43992

flagged as non-issue because this belongs to a new unreleased feature, however, we see this as showstopper for releasing continuous data frames

- do not let checkpointing fail if indexes got deleted
- treat missing seqNoStats as just created indices (checkpoint 0)
- loglevel: do not treat failed updated checks as error

fixes elastic#43992
@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core

Copy link
Member

@benwtrent benwtrent left a comment

Choose a reason for hiding this comment

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

👍 We no longer throw NotFound exceptions on missing indices
👍 We handle indices going away between old checkpoints and new checkpoints
👍 We only expand to open indices

It may be good to log+audit when we detect an index was removed. It should just be an info as it may be a desired action, but it would be good to give indication that we are no longer seeing a previously checkpointed index.

Copy link
Contributor

@droberts195 droberts195 left a comment

Choose a reason for hiding this comment

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

LGTM2

@hendrikmuhs hendrikmuhs merged commit eb50f47 into elastic:master Jul 16, 2019
hendrikmuhs pushed a commit to hendrikmuhs/elasticsearch that referenced this pull request Jul 16, 2019
make checkpointing more robust:

- do not let checkpointing fail if indexes got deleted
- treat missing seqNoStats as just created indices (checkpoint 0)
- loglevel: do not treat failed updated checks as error

fixes elastic#43992
hendrikmuhs pushed a commit to hendrikmuhs/elasticsearch that referenced this pull request Jul 16, 2019
make checkpointing more robust:

- do not let checkpointing fail if indexes got deleted
- treat missing seqNoStats as just created indices (checkpoint 0)
- loglevel: do not treat failed updated checks as error

fixes elastic#43992
hendrikmuhs pushed a commit that referenced this pull request Jul 16, 2019
make checkpointing more robust:

- do not let checkpointing fail if indexes got deleted
- treat missing seqNoStats as just created indices (checkpoint 0)
- loglevel: do not treat failed updated checks as error

fixes #43992
hendrikmuhs pushed a commit that referenced this pull request Jul 16, 2019
make checkpointing more robust:

- do not let checkpointing fail if indexes got deleted
- treat missing seqNoStats as just created indices (checkpoint 0)
- loglevel: do not treat failed updated checks as error

fixes #43992
droberts195 added a commit to droberts195/elasticsearch that referenced this pull request Jul 19, 2019
Since elastic#44344 we use IndicesOptions.LENIENT_EXPAND_OPEN
when deciding which indices to include in checkpoint
calculation. This change uses the same option when
deciding which indices to search for data and which
indices to get mappings from, otherwise there is a
potential mismatch between the checkpoint details and
what is searched elsewhere.
droberts195 added a commit that referenced this pull request Jul 22, 2019
Since #44344 we use IndicesOptions.LENIENT_EXPAND_OPEN
when deciding which indices to include in checkpoint
calculation. This change uses the same option when
deciding which indices to search for data and which
indices to get mappings from, otherwise there is a
potential mismatch between the checkpoint details and
what is searched elsewhere.
droberts195 added a commit that referenced this pull request Jul 22, 2019
Since #44344 we use IndicesOptions.LENIENT_EXPAND_OPEN
when deciding which indices to include in checkpoint
calculation. This change uses the same option when
deciding which indices to search for data and which
indices to get mappings from, otherwise there is a
potential mismatch between the checkpoint details and
what is searched elsewhere.
droberts195 added a commit that referenced this pull request Jul 22, 2019
Since #44344 we use IndicesOptions.LENIENT_EXPAND_OPEN
when deciding which indices to include in checkpoint
calculation. This change uses the same option when
deciding which indices to search for data and which
indices to get mappings from, otherwise there is a
potential mismatch between the checkpoint details and
what is searched elsewhere.
@jakelandis jakelandis removed the v8.0.0 label Jul 26, 2021
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.

[ML] Continuous data frame should be more robust to new and deleted indices
5 participants