Currently events are stored in the database and users need to use the API to poll them and be notified of stack changes. This particularly painful for hooks, where Heat is waiting for user input.
To let the user customize how he wants to get event, we add a key to the environment to specify where they should go:
event_sinks: - type: zaqar-queue target: myqueue ttl: 30
event_sinks is a list of target with a type specified, and possible options (like ttl here being a Zaqar option). Zaqar will be the first implementation available, sending all the events to the specified queue.
We’ll use an entry points with stevedore to allow pluggable implementations.
To not add network calls to the critical path of every single event, the publication will be delegated to a thread and thus be asynchronous. The drawback is that potential errors won’t be presented to users.
Events will continue to go in the database.
Instead of making it a user configurable option, we could make it a global option for the Heat administrator. It makes it less discoverable, and is probably not necessary for every users. We also lose configurability.