Actions
Story #21074
openMigrate "workflow" table to be backed by collections but maintain API
Start date:
Due date:
% Done:
0%
Estimated time:
Story points:
-
Description
Idea: the "workflow" table is an odd duck. It stores a single data string in the "definition" field, but doesn't support properties, versioning, trashing, etc. We want these things for workflows but we don't want to duplicate all the logic. It would be better if we could just store workflows in collections.
However, eliminating the "workflows" API endpoint would be disruptive, as Workbench and arvados-cwl-runner both rely on it.
To migrate workflow records to collections, I propose the following:
- Workflow records are migrated over to collections. The "name" and "description" fields are straightforward. The contents of the "definition" field would be put in Keep as "workflow.yml". The collection record would have metadata "type: workflow"
- The Workflow endpoint is migrated to controller
- On controller, GET/PUT/POST operations are translated to apply to only collections with "type: workflow". The contents of "definition" would be read from / written to Keep.
- when going through the workflows endpoint, collection UUIDs would be mapped to workflow UUIDs with the same cluster and random part just with
7fd4esubstituting for4zz18 - Going forward, we can choose to either expose additional fields and capabilities through the workflows endpoint (properties, versioning), or phase out the workflows endpoint by updating client code that uses workflows to instead use collections of "type: workflow"
Related issues
Updated by Peter Amstutz about 2 months ago
- Related to Story #19132: Registered workflow improvements added
Actions