Skip to content

Conversation

@hendrikmuhs
Copy link

@hendrikmuhs hendrikmuhs commented Dec 17, 2018

Default the stop data frame job API is async, this change adds an option to block until the job has really stopped. This is useful for testing and a prerequisite for a UI. wait_for_completion follows similar namings in rollup and reindex.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/ml-core

Copy link
Member

@benwtrent benwtrent left a comment

Choose a reason for hiding this comment

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

Is there any mechanism for the end user to see the status of the request? Or to see when it is completed?

From what I can tell, since we do not return a task ID for the action, there is no way for the end user to check the completion of the task. I may be wrong about this as the way this async/sync request handling is done is different than others I have seen in the code base.

Copy link
Member

Choose a reason for hiding this comment

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

timeout already exists with the ActionRequest of which this is a descendant.
Is there a reason for not using that field?

Copy link
Author

Choose a reason for hiding this comment

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

I changed it to reuse the timeout value from the base class. As discussed it is a bit ugly, but I hope I found a good compromise.

@hendrikmuhs
Copy link
Author

@benwtrent

The stats API enables the user to check the state of a data frame:

GET _data_frame/jobs/my_job/_stats

example output:

{
  "count" : 1,
  "jobs" : [
    {
      "id" : "my_job",
      "state" : {
        "job_state" : "started",
        "current_position" : {
          "reviewer" : "XFEDSvjzlLR3Q7wsUw"
        },
        "generation" : 1
      },
      "stats" : {
...

So the task id is basically the job. Right now there is a 1:1 relationship between a job and a task, but that might change. With other words, a user interacts with the high level concept job, the underlying task is an implementation detail.

Coming back to this PR. When issuing a stop, the job_state above changes from started to stopped, that happens async per default, but sync if you use wait_for_completion.

This is API-wise no different than rollup(#34811), but different to reindex, because in reindex you interact with tasks.

I hope this makes it more clear.

@hendrikmuhs hendrikmuhs force-pushed the feature/fib-wait-for-completion branch from 348fdf8 to e2327e1 Compare December 18, 2018 12:01
@hendrikmuhs
Copy link
Author

run gradle build tests 2

@hendrikmuhs hendrikmuhs merged commit 972c063 into elastic:feature/fib Dec 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>feature :ml Machine learning

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants