Page History

...

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 Development Notes

There is not a super adequate amount of developer API documentation inside the Python code for StackStorm. A certain amount of reverse engineering was required to create the new file detector. Here are some notes about what I discovered while doing this implementation.

Sensors

You're going to get your sensor instantiated exactly once.

A lot of weird stuff about the API is somewhat explained by the fact that your sensor can define many trigger types. Each trigger type has a parameter type and a payload type. These are expressed using JSON Schema. So the Python code winds up accepting and producing lots of dictionaries representing JSON.

Triggers get manufactured by StackStorm when the user configures a rule to depend on a trigger type coming out of your sensor, but they aren't instances of a real class, just a dictionary. When this happens, StackStorm will call add_trigger on your sensor instance with a trigger dictionary. The most interesting slot of this to you will be the trigger's parameter, which will have whatever parameters you defined in the parameter schema in the YAML file. So for the directory watcher, this is the directory to check. It could be other things too, like the glob string to use.

It's important to hold onto this configuration somewhere because StackStorm will then issue update and delete calls with the same dictionary, and you need the dictionary to call sensor_service.dispatch with. It's these calls that create events in the StackStorm system which the action in a rule will catch.

State

In terms of saving state, using your sensor instance isn't super safe, because the service could go down and come back. Helpfully, StackStorm provides a key-value store that is keyed to your instance. Unhelpfully, it's a key-value store, so you'll have to invent keys for whatever properties you want to hold on to for longer than the life of a single instance.

Development Cycle

The easiest thing to do, following the advice of StackStorm Docker, is this:

1. Clone the docker repo
2. Run docker compose up -d .
3. Develop your pack in the packs.dev directory inside the cloned Docker repo
4. Run docker-compose exec st2client bash and then change to the directory packs.dev 
5. Run st2 pack install file://$PWD/<your-pack> 
6. Navigate to the UI at http://localhost and create a rule using your actions and sensors

Whenever you modify the pack sourcecode, you'll need to rerun st2 pack install file://$PWD/<your pack> . In another console, follow the logs with: docker compose logs -f

This is fairly onerous. I am not entirely sure what can be done about it at this time.

StackStorm Checklist

•  Sensor: Filesystem monitor
  
•  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