As discussed in #70, this adds an endpoint to the API server to collect status events from clusters. As discussed in #77, the kick server will use this endpoint to submit information about its services starting up or stopping.
Details
This adds a new resource, deployment, and three new paths, with the following actions:
POSTing to /deployments creates a new deployment, and requires a deployment_id and a cluster_id.
The GET action lists all deployments known to the system (filtering will be available once https://github.com/pandastrike/pbx/issues/19 has been sorted out).
The /deployment/:id path should be relatively self-explanatory. In fact, we might want to get rid of DELETE because we don't need it, and this should be considered archival information.
Finally, the /status path accepts status messages from the kick server, and adds them to the corresponding deployment. This will go away in a future version when we implement message queueing with Mutual.
Summary
As discussed in #70, this adds an endpoint to the API server to collect status events from clusters. As discussed in #77, the kick server will use this endpoint to submit information about its services starting up or stopping.
Details
This adds a new resource,
deployment, and three new paths, with the following actions:POSTing to
/deploymentscreates a new deployment, and requires adeployment_idand acluster_id. The GET action lists all deployments known to the system (filtering will be available once https://github.com/pandastrike/pbx/issues/19 has been sorted out).The
/deployment/:idpath should be relatively self-explanatory. In fact, we might want to get rid of DELETE because we don't need it, and this should be considered archival information.Finally, the
/statuspath accepts status messages from the kick server, and adds them to the corresponding deployment. This will go away in a future version when we implement message queueing with Mutual.