Workflow with pause modules have to be run through the new workflow scheduling plugin framework - so these will always force jobs to be queued in the background. The deployer can also now choose to have workflows scheduled this way if a workflow has a minimum number of steps (set at a very high 250 right now) or if it uses collections (currently this defaults to False). These options are meant as transient options that will disappear once all workflows a scheduled this way - but there needs to be better UI in place before making that switch as well as more testing. These options are just meant to give people running really large workflows a way to start exploring the scheduling framework option.
New module type that pauses a workflow and gives time for the runner to review it before proceeding with execution.
- Introduce concept of beta workflow modules - I guess we should just keep the pause module as beta until their is a UI to support it.
- Extracts base class ouptut of InputModule for modules that are "simple" - i.e. their configuration state is represented as a dictionary and configuration form is rendered via the generic template.
- Test Cases (for this changeset and a bunch of stuff that is now testable with the pause module in place from the scheduling framework commit).
Models:
Workflow invocations have been augmented with significantly more state - inputs, parameters, runtime step state, are all being tracked now. Workflow invocations have a state that can be changed over time, the UUIDs generated for workflow invocations in Pull Request #465 have to be persisted so they can be reused when scheduling new jobs for theworkflow invocation. Workflow invocation steps now have an action parameter for persisting state provided by users during the execution of the workflow (see forthcoming PauseModule for further details).
Some initial elements of these model changes were based on model changes in Kyle Ellrott's Galaxy farm work (https://bitbucket.org/kellrott/galaxy-farm/branch/workflow_migrate). I made heavy modifications to the model to enforce referential integrity on parameter to workflow step mappings and made some cosmetic changes various other details.
Scheduling Plugins:
Used the pattern setup with dependency resolvers and job metrics to build a dynamic plugin infrastructure for defining workflow schedulers. I hesistate calling anything with only one implementation a plugin infrastructure, but I am confident enough that the combination of persisted workflow request combined with scheduler tag could be used to build a galaxy-farm plugin that would wait for another Galaxy instance to become available and it would pull the workflow down and
This work piggy backs on Galaxy job handlers to have workflow scheduled in the background (i.e. during submission each workflow being scheduled in the background is assigned a unique job handler and only that job handler thread will process the workflow). It should be pretty easy to allow the definition of a new kind of handler - that is a workflow handler instead of a job handler if that is of interest.
I will probably move a bunch of stuff that is happening in workflow/scheduling_manager.py more into the scheduler itself so that it can be more configurable and closer to a true plugin.
API:
There are a number of new API points here for flushing out dealing with workflow invocations (called usages in existing parlance).
- POST /api/workflows/{encoded_workflow_id}/usage
Schedule a worklfow to be run in the background and return just the workflow invocation information.
RESTfully speaking this should be plural but the matching GET endpoint is likewise usage and not usages - so I am favoring consistency over RESTful correctness here. Also, likewise creating a 'usage' feel like odd - I would like to make all of the usage endpoints aliases to a more RESTfully correct invocations endpoints.
The existing workflow run API endpoints still work and still work the way they use usually - but the output now includes all of the workflow invocation to_dict stuff as well as the list of outputs it initially used. Once everything is scheduled this way - that list of outputs is going to have to disappear but hopefully people can start using the invocation stuff now to help the transition.
- DELETE /api/workflows/{workflow_id}/usage/{usage_id}
Cancel a scheduled workflow invocation.
- GET /api/workflows/{workflow_id}/usage/{usage_id}/steps/{step_id}
Get information about a workflow invocation step.
- PUT /api/workflows/{workflow_id}/usage/{usage_id}/steps/{step_id}
Update a workflow invocation step - for ones with modifiable state. Extension point added to workflow modules to support this but it is unused by all existing worklfow modules. A subsequent PauseModule will use this to either continue or cancel a workflow invocation at a particular step.
Modules:
Workflow modules can now define new methods for dealing with recovering state and interacting with user requests.
Testing:
One can issue a workflow request by running the following test.
./run_tests.sh -api test/api/test_workflows.py:WorkflowsApiTestCase.test_workflow_request
This again falls under the umbrella of making workflow modules more like true plugins. This should allow one to add new modules downstream without needing to modify templates/webapps/galaxy/workflow/editor.mako. One can imagine a new API endpoint for the new load_module_sections method will be useful as the editor UI shifts to a single page app and actual API clients need to determine what workflow modules are available. Such an API endpoint is not included but would be easy to add now.
These can have 16 MB of data instead of 65 KB - tool shed repositories have encountered problems with the 65 KB limit - though other columns might as well.
From Carl: "Yeah - that looks fine for stable. A better fix is probably adding the pair index directly into the DOM and getting it there - I'll add that to the 'Iteration 2' card. I'll approve now if you want to do the request."
Aysam Guerler