...
Option 3 seems like it would be the most irritating and least helpful, except for the fact that it would be totally sufficient for this problem and requires no particular state.
Queue Runner/Loaders
These come in two flavors: ALMA and VLBA. They share a similar architecture, which is very interesting and cool (I wrote the first one) but mainly exists to enable throttling of executions at a certain number, which is an intrinsic functionality of Workspaces (capability queue limits). So it should not be necessary to bring much of the complexity along for the migration.
ALMA
Despite the names, AlmaReingestionQueueLoader actually accounts for three things:
- Reingestion of raw ASDMs from the ALMA instrument
- Reingestion of calibrations from ALMA
- Marking ASDMs as not calibrateable
What is needed to implement this is:
- Source of ALMA ASDMs to load
- Source of ALMA calibrations to load
- Action of marking ASDM as not calibrateable
VLBA
The VLBA system is simpler, it only handles the appearance of VLBA data to ingest. There is no automatic calibration of VLBA data. What is needed to implement this is therefore only a source of VLBA data to load.
StackStorm Checklist
- Sensor: Filesystem monitor trigger
- Action: Workspaces Capability create-and-run
- Action: Workspaces Workflow create-and-run
- Sensor: ALMA ASDMs to load
- Sensor: ALMA calibrations to load
- Sensor: VLBA data to load
- Action: Mark ASDM as not calibrateable