Skip to content

Conversation

@droberts195
Copy link

This change moves the update to the results index mappings
from the open job action to the code that starts the
autodetect process.

When a rolling upgrade is performed we need to update the
mappings for already-open jobs that are reassigned from an
old version node to a new version node, but the open job
action is not called in this case.

Backport of #37706

David Roberts added 4 commits January 23, 2019 10:55
This change moves the update to the results index mappings
from the open job action to the code that starts the
autodetect process.

When a rolling upgrade is performed we need to update the
mappings for already-open jobs that are reassigned from an
old version node to a new version node, but the open job
action is not called in this case.

Closes elastic#37607
@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core

@droberts195
Copy link
Author

This backport has even more differences to #37706 than #37753 - I had to incorporate some portions of #37483.

Copy link
Member

@davidkyle davidkyle left a comment

Choose a reason for hiding this comment

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

LGTM

Made the test tolerant to index upgrade being run
in between the old/mixed/upgraded portions.  This
can occur because the rolling upgrade tests all
share the same indices.
@droberts195
Copy link
Author

I added the fix from #37769 into this PR.

@droberts195 droberts195 merged commit f405c2c into elastic:6.6 Jan 29, 2019
@droberts195 droberts195 deleted the update_results_mappings_on_process_start_66 branch January 29, 2019 09:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants