Story #21074


Migrate "workflow" table to be backed by collections but maintain API

Added by Peter Amstutz about 2 months ago. Updated about 2 months ago.

Assigned To:
Target version:
Start date:
Due date:
% Done:


Estimated time:
Story points:


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:

  1. 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"
  2. The Workflow endpoint is migrated to controller
  3. 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.
  4. when going through the workflows endpoint, collection UUIDs would be mapped to workflow UUIDs with the same cluster and random part just with 7fd4e substituting for 4zz18
  5. 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

Related to Arvados Epics - Story #19132: Registered workflow improvementsIn Progress09/01/202312/31/2023

Actions #1

Updated by Peter Amstutz about 2 months ago

  • Description updated (diff)
Actions #2

Updated by Peter Amstutz about 2 months ago

  • Related to Story #19132: Registered workflow improvements added

Also available in: Atom PDF