Events are small JSON documents that describe an event that happens in a system. Events come in many forms but usually they indicate things like startup, shutdown, aliveness, problems or major completed tasks. They tend to be informational and so should be considered lossy - in other words do not expect to get a
shutdown event for every shutdown that happens, some kinds of shutdown can prevent it from reaching you. Likewise startups where the middleware connection is flakey.
These events come in many flavours and there are not really many standards around for this stuff, one effort cloudevents from the CNCF looks to be on a good path and once things mature we’ll look to adopt them as the underlying format for our lifecycle messages too.
In Choria we call these Lifecycle Events. I recently released an initial version
1.0.0 of the package that manages these, this post will introduce what we have today and what we use them for.
These kinds of event allow other tools to react to events happening from Choria components, some uses:
- Create a dashboard of active versions of a component by passively observing the network - use startup, shutdown and alive events.
- React to nodes starting up by activating other orchestration systems like continuous delivery systems
- React to a specific component starting up and provision them asap
There are many other cases where an event flow is useful and in time we will add richer event types.
Today Choria Server, Choria Backplane and Choria Provisioner produce events while Choria Provisioner consumes them. We are a bit conservative with when and where we emit them as the clusters we support can be in the 50k node range we need to consider each type of event and the need for it carefully.
Read on for full details.