Event Triggers

When processing notification events, it is often useful to aggregate data from notifications that are emitted over a wide range of time. These may arrive at multiple different collectors (if there are multiple collector workers) or even in random order, due to the vaugeries of rabbitmq, or different components within an openstack project (like nova) working at varying rates. Triggers allow for such aggregation.
Triggers have a Definition with a pattern, a trigger criteria, a ttl, a triggered notification pipeline, and an optional expiration notification pipeline.
The pattern is a specification for event types and notification data values that match the trigger. When the first notification that matches a trigger's definition pattern is detected, a Trigger is created. The trigger keeps a list of notifications that have matched it's pattern. When the criteria is met, the trigger fires, sending all of the collected notifications to the associated pipeline as a batch for processing. If the ttl expires without the trigger firing, the collected notifications are sent to the expiration pipeline if there is one. When fired or expired, the trigger is deleted.
Example:
You want to meter average build time statistics.
A trigger for build_time:$instance_uuid is defined, with a pattern matching compute.instance.create.* events for a given instance_uuid. The criteria is that there is at least one compute.instance.create.start event and at least one compute.instance.create.end. The ttl is 4 hours, (after which the user considers the build failed) . There is a a notification pipeline that filters out extra .start events (which can be generated by nova's rescheduling mechanism), and generates a timedelta sample between the timestamps for the .start and .end events, to drive an average build time meter. If the ttl expires, the expiration pipeline generates a sample to increment a cumulative build failure meter.