You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nodes running 7.10 or above must not be allowed to be assigned data frame analytics jobs whose persistent task params were created in 7.9 or earlier, as the mappings on the destination index will be for the pre-#61104 results format.
Nodes running 7.9 or earlier must not be allowed to be assigned data frame analytics whose persistent task params were created in 7.10 or later, as the mappings on the destination index will be for the post-#61104 results format.
Those two rules nicely cover jobs that are running during rolling upgrade and need to be moved to a different node part way through. There is another case where having the version in the persistent task params doesn't help, and that is if someone attempts to start a job in 7.10 or above that was manually stopped part way through its run in 7.9 or earlier. We need to prevent this too. We store the version that created the destination index in its metadata. Hopefully we can use this to prevent a job being started if its destination index is too old for the latest results format.
The text was updated successfully, but these errors were encountered:
PR #43880 "adds the analytics version in the persistent task params as this allows us to prevent tasks to run on unsuitable nodes in the future."
Due to #61104 the future is now.
Nodes running 7.10 or above must not be allowed to be assigned data frame analytics jobs whose persistent task params were created in 7.9 or earlier, as the mappings on the destination index will be for the pre-#61104 results format.
Nodes running 7.9 or earlier must not be allowed to be assigned data frame analytics whose persistent task params were created in 7.10 or later, as the mappings on the destination index will be for the post-#61104 results format.
Those two rules nicely cover jobs that are running during rolling upgrade and need to be moved to a different node part way through. There is another case where having the version in the persistent task params doesn't help, and that is if someone attempts to start a job in 7.10 or above that was manually stopped part way through its run in 7.9 or earlier. We need to prevent this too. We store the version that created the destination index in its metadata. Hopefully we can use this to prevent a job being started if its destination index is too old for the latest results format.
The text was updated successfully, but these errors were encountered: