Move persistent tasks to core #28455
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A persistent action is a transport-like action that is using the cluster state instead of transport to start tasks. This allows persistent tasks to survive restart of executing nodes. A persistent action can be implemented by extending TransportPersistentAction. TransportPersistentAction will start the task by using PersistentActionService, which controls persistent tasks lifecycle. See TestPersistentActionPlugin for an example implementing a persistent action. Original commit: elastic/x-pack@5e83f1b
Similarly to task status on normal tasks it's now possible to update task status on the persistent tasks. This should allow updating the state of the running tasks (such as loading, started, etc) as well as store intermediate state or progress. Original commit: elastic/x-pack@048006b
Original commit: elastic/x-pack@3bf4025
Store currently running persistent tasks in a map instead of a list. Original commit: elastic/x-pack@f88c9ad
Also replaced the DELETING status from JobState with a boolean flag on Job. The state of a job is now stored inside a persistent task in cluster state. Jobs that aren't running don't have a persistent task, so I moved that notion of being deleted to the job config itself. Original commit: elastic/x-pack@21cd19c
This commit moves persistent tasks from ClusterState.Custom to MetaData.Custom and adds ability for the task to remain in the metadata after completion.
…pdate` field was added to `PersistentTaskInProgress` class. This will allow persistent task implementors to detect whether the executor node has changed or has been unset since the last status update has occured.
This commit allows persistent actions to indicate why a task was or wasn't assigned to a certain node.
…ir writable names Refactors xcontent serialization of Request and Status to use their writable names instead of action name. That simplifies the parsing logic, allows reuse of the same status object for multiple actions and is consistent with how named objects in xcontent are used.
PersistentTask -> NodePersistentTask PersistentTasksInProgress -> PersistentTasks PersistentTaskInProgress -> PersistentTask
Removes the transport layer dependency from PersistentActions, makes PersistentActionRegistry immutable and rename actions into tasks in class and variable names.
If a persistent task throws an exception, the persistent tasks framework will no longer try to restart the task. This is a temporary measure to prevent threshing the cluster with endless restart attempt. We will revisit this in the future version to make the restart process more robust. Please note, however, that if node executing the task goes down, the task will still be restarted on another node.
…lastic#842) Refactors NodePersistentTask and RunningPersistentTask into a single AllocatedPersistentTask. Makes it possible to update Persistent Task Status via AllocatedPersistentTask.
…lastic#853) The stopped and removeOnCompletion flags are not currently used, this commit removes them for now to simplify things.
This method allows to wait for tasks to change their status to match the supplied predicate.
…lastic#923) In order to prevent tasks state updates by stale executors, this commit adds a check for correct allocation id during status update operation.
…or job and datafeed status and use PersistentTasksService#removeTask(...) to force close job and force stop datafeed.
…tus (elastic#935) Add a check for the current state waitForPersistentTaskStatus before waiting for the next one. This fixes sporadic failure in testPersistentActionStatusUpdate test. Fixes elastic#928
This commit is response to the renaming of the random ASCII helper methods in ESTestCase. The name of this method was changed because these methods only produce random strings generated from [a-zA-Z], not from all ASCII characters.
…er (elastic#937) PersistentTasksService methods are not using ActionListener<PersistentTask<?>> instead of PersistentTaskOperationListener.
Retries should be already handled by TransportMasterNodeAction, there is no need to introduce another retry layer in Persistent Tasks code.
…eration (elastic#1032) Instead of having a separate listener for indicating that the current task is finished, this commit is switching to use allocated object itself.
… to allow callers to wait when an executor node has updated its task status.
…ic#1035) This commit switches from long persistent task ids to caller-supplied string persistent task ids.
…#1057) Removes the last pieces of ActionRequest from PersistentTaskRequest and renames it into PersistTaskParams, which is now just an interface that extends NamedWriteable and ToXContent.
… same as their task (elastic#1072) Changes persistent task serialization and forces params and status to have the same writeable name as the task itself.
Removes a method that is no longer used in production code. Relates to elastic#957
Companion PR to elastic#25778
These members are default initialized on contruction and then set by the init() method. It's possible that another thread accessing the object after init() is called could still see the null/0 values, depending on how the compiler optimizes the code.
* Moves more classes over to ToXContentObject/Fragment * Removes ToXContentToBytes * Removes ToXContent from Enums * review comment fix * slight change to use XContantHelper
…nodeOperation(...) method
This change removes the InternalClient and the InternalSecurityClient. These are replaced with usage of the ThreadContext and a transient value, `action.origin`, to indicate which component the request came from. The security code has been updated to look for this value and ensure the request is executed as the proper user. This work comes from elastic#2808 where @s1monw suggested that we do this. While working on this, I came across index template registries and rather than updating them to use the new method, I replaced the ML one with the template upgrade framework so that we could remove this template registry. The watcher template registry is still needed as the template must be updated for rolling upgrades to work (see elastic#2950).
Persistent tasks portion of elastic#23250
…elegates to PersistentTasksService#waitForPersistentTaskStatus(...) This allows persistent tasks executor implementations to not have an instance of PersistentTasksService.
Made persistent tasks executors pluggable.
jasontedor
approved these changes
Feb 1, 2018
There was a problem hiding this comment.
LGTM. Note that using the merge button is not an option here as it will squash everything into one commit losing history. I went through similar troubles with #28453 on a much smaller scale.
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
May 21, 2018
Persistent tasks was moved from X-Pack to core in elastic#28455. However, registration of the named writables and named X-content was left in X-Pack. This change moves the registration of the named writables and named X-content into core. Additionally, the persistent task actions are no longer registered in the X-Pack client plugin, as they are already registered in ActionModule.
droberts195
added a commit
that referenced
this pull request
May 24, 2018
Persistent tasks was moved from X-Pack to core in #28455. However, registration of the named writables and named X-content was left in X-Pack. This change moves the registration of the named writables and named X-content into core. Additionally, the persistent task actions are no longer registered in the X-Pack client plugin, as they are already registered in ActionModule.
droberts195
added a commit
that referenced
this pull request
May 24, 2018
Persistent tasks was moved from X-Pack to core in #28455. However, registration of the named writables and named X-content was left in X-Pack. This change moves the registration of the named writables and named X-content into core. Additionally, the persistent task actions are no longer registered in the X-Pack client plugin, as they are already registered in ActionModule.
droberts195
added a commit
that referenced
this pull request
May 24, 2018
Persistent tasks was moved from X-Pack to core in #28455. However, registration of the named writables and named X-content was left in X-Pack. This change moves the registration of the named writables and named X-content into core. Additionally, the persistent task actions are no longer registered in the X-Pack client plugin, as they are already registered in ActionModule.
jpountz
added
>non-issue
:Distributed/Task Management
|
Pinging @elastic/es-distributed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Persistent tasks are build on top of node tasks and provide functionality to restart a task to run on a different coordination node in case the coordinating node is no longer available. It is up to a persistent task implementation to keep track of status, so that in case the task is restarted, the task can continue were it left off before it was restarted.