This is closely related to #67 but a little different. When the user accesses the status of their deployment on the cluster, they won't just be looking at a random collection of services. If we remember the CAM model, the user should see a list of applications and their microservice children.
We need to also register applications with the kick server. This can be done by the githook as it launches services onto the cluster. Its first step could be to curl the kick server and tell it about a service and to expect applications. This information would be piped to the Huxley API and made available to the user.
Please propose a schema to handle this efficiently.
This is closely related to #67 but a little different. When the user accesses the status of their deployment on the cluster, they won't just be looking at a random collection of services. If we remember the CAM model, the user should see a list of applications and their microservice children.
We need to also register applications with the kick server. This can be done by the githook as it launches services onto the cluster. Its first step could be to curl the kick server and tell it about a service and to expect applications. This information would be piped to the Huxley API and made available to the user.
Please propose a schema to handle this efficiently.