Move persistent tasks to core #28455

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

Original commit: elastic/x-pack@7f44b41

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.

…task is stale.

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.

PersistentTasksCustomMetadata was using a generic param named `Params`. This conflicted with the imported interface `ToXContent.Params`. The java compiler was preferring the generic param over the interface so everything was fine but Eclipse apparently prefers the interface int his case which was screwing up the Hierarchy and causing compile errors in Eclipse. This changes fixes it by renaming the Generic param to `P`

) Persistent tasks should verify that completion notification is done for correct version of the task, otherwise a delayed notification from an old node can accidentally close a newly reassigned task.

Companion commit to elastic#24236

The current state is readily available as a parameter

With the leniency in Version.java we missed to really setup BWC testing for static indices. This change brings back the testing and adds missing bwc indices. Relates to elastic#24732

This is the x-pack side of the removal of `accumulateExceptions()` for both `TransportNodesAction` and `TransportTasksAction`. There are occasional, random failures that occur during API calls that are silently ignored from the caller's perspective, which also leads to weird API responses that have no response and also no errors, which is obviously untrue.

Removes a method that is no longer used in production code. Relates to elastic#957

Companion PR to elastic#25778

…lastic#2117)

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

@s1monw

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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move persistent tasks to core #28455

Move persistent tasks to core #28455

Commits on Jan 31, 2018