Skip to content

Conversation

@benwtrent
Copy link
Member

@benwtrent benwtrent commented Aug 12, 2020

When a user upgrades between versions, they may stop their ML jobs.

Then when the upgrade is complete, they will want to open the jobs again.

But, when opening a job, we attempt to clear out the jobs finished_time. If the job configuration has adjusted between the versions (i.e. added a new field), it will dynamically update the .ml-config index.

We should instead manually change the mapping to be the updated version.

Fixes #61157

@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core (:ml)

@benwtrent benwtrent changed the title [ML] ensure config index is updated before clearing finished_time [ML] ensure .ml-config index is updated before clearing anomaly job's finished_time Aug 12, 2020
Copy link

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

LGTM

@benwtrent benwtrent merged commit 131f2e5 into elastic:master Aug 13, 2020
@benwtrent benwtrent deleted the bugfix/ml-update-config-index-before-write branch August 13, 2020 11:19
benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Aug 13, 2020
…astic#61064)

When a user upgrades between versions, they may stop their ML jobs.

Then when the upgrade is complete, they will want to open the jobs again.

But, when opening a job, we attempt to clear out the jobs finished_time. If the job configuration has adjusted between the versions (i.e. added a new field), it will dynamically update the .ml-config index.

We should instead manually change the mapping to be the updated version.
benwtrent added a commit to benwtrent/elasticsearch that referenced this pull request Aug 13, 2020
…astic#61064)

When a user upgrades between versions, they may stop their ML jobs.

Then when the upgrade is complete, they will want to open the jobs again.

But, when opening a job, we attempt to clear out the jobs finished_time. If the job configuration has adjusted between the versions (i.e. added a new field), it will dynamically update the .ml-config index.

We should instead manually change the mapping to be the updated version.
benwtrent added a commit that referenced this pull request Aug 13, 2020
…1064) (#61086)

When a user upgrades between versions, they may stop their ML jobs.

Then when the upgrade is complete, they will want to open the jobs again.

But, when opening a job, we attempt to clear out the jobs finished_time. If the job configuration has adjusted between the versions (i.e. added a new field), it will dynamically update the .ml-config index.

We should instead manually change the mapping to be the updated version.
benwtrent added a commit that referenced this pull request Aug 13, 2020
…1064) (#61085)

When a user upgrades between versions, they may stop their ML jobs.

Then when the upgrade is complete, they will want to open the jobs again.

But, when opening a job, we attempt to clear out the jobs finished_time. If the job configuration has adjusted between the versions (i.e. added a new field), it will dynamically update the .ml-config index.

We should instead manually change the mapping to be the updated version.
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] Incorrect mappings on .ml-config index after upgrading to 7.9.0

4 participants