search

daisy / pipeline-webui

A Web User Interface for the DAISY Pipeline 2
Other
3 stars 2 forks source link

Re-running jobs #23

Closed bertfrees closed 9 years ago

bertfrees commented 9 years ago

Make it possible to re-run jobs from the web UI.

Use case 1: A job failed because of a bug in the script. In the next version the bug has been fixed and the user wants to check that without having to upload the files and specifying the options again. The job id may have been included in the bug report as reference.

Use case 2: A job succeeded but the result is not satisfying. In the next version the script has been improved.

Use case 3: A job succeeded but the user decides to run it again immediately with different options / inputs.

josteinaj commented 9 years ago

Would it be easier to implement this in the engine + Web API instead of the Web UI? Or did we discuss that at some point and decide that it's the responsibility of each client?

bertfrees commented 9 years ago

We discussed in Nancy whether templates should be responsibility of the engine and we decided it's not. Didn't find it in the notes though.

Then in a DP2 chat some time ago we discussed whether the engine should store input files etc for jobs and Javi was not in favor of that either.

josteinaj commented 9 years ago

Mhm, ok. I'll put it in the Web UI then (as soon as I get the webui compiling with play 2.4.x...)

bertfrees commented 9 years ago

We could check again in the next DP2 call. Do you think it's doable to write the feature it in such a way that it easily portable?

josteinaj commented 9 years ago

Ok.

Yeah I could possibly put it in clientlib-java. Along with templates.

bertfrees commented 9 years ago

SGTM

josteinaj commented 9 years ago

@bertfrees When re-running a job, it will technically be a new job under the hood. What do you think should be done with the previous job? Should we provide the log, report and results for the previous jobs through the Web UI as well, or should we delete the previous job and just present the newest job?

bertfrees commented 9 years ago

I'm unsure. I don't think I would delete it. Maybe just a link to the original job (job ID)? Like is done when you clone a Github repository?

josteinaj commented 9 years ago

This one you mean?

github fork

Then how about something like this?

webui fork

Also, thinking about forking, would you be able to edit the arguments for a job when re-running it? I was thinking you wouldn't, but maybe I should rethink that...

bertfrees commented 9 years ago

Nice photoshopping! :smile: (or gimping)

Yes my idea was that you would be able to edit. Use case 3 in the issue description. Editing would of course be possible with templates, so it seems logical to also support it when re-running a job. (A template is basically just a job, possibly incomplete, and that hasn't been run yet.)

josteinaj commented 9 years ago

GiMP FTW :)

I think the simplest probably is to just create a completely new job when re-running a job. There would be no special linking between the jobs.

If you can edit a job before rerunning it then that job is essentially a template for the new job. You should probably be able to save a job as a template for future use then. The plan for editing templates is currently to have some buttons where you set the job options. If you store a template without running a job, that's quite similar to creating a job but not running it. Maybe creating a job but not running it could be an option in the future...

A global setting can determine whether or not to delete the original job. For our project it is probably most useful to keep the original job so we can compare logs, results etc.. On the other hand, in a day-to-day production environment you will want to minimize disk space usage, especially when producing TTS books.

If we want linking between old and new jobs, we can implement that later.

bertfrees commented 9 years ago

OK a setting for deleting original job or not sounds reasonable.

bertfrees commented 9 years ago

Can be closed too, I think.