Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Adds service update started event #6611
This PR fires a service update started event when the supervisor sees that a new hab package is available and thus starts the package update process. Automate uses this event to help determine and display the deployment status of a service.
Note: there's work in progress to refactor the supervisor to perform certain operations, including starting packages, asynchronously. Until this work is done, providing additional deployment events (service update completed, service update failed) is awkward because we don't have a concrete handle on when these events occur without adding more state as a stopgap. I'm thinking it might be best to let Automate derive completed and failure states on its side until we get the supervisor refactored and can implement additional events in the correct way. One possible way Automate might accomplish this would be to compare the update fully-qualified package identifier from the service update started event with the fully-qualified package identifier from the most recent service started event for a given service. If they match, Automate could assume a successful update. If this is not the case (and a specified period of time has passed), Automate could assume an update failure.
There are nuances to this we'd need to discuss, e.g., multiple entities trying to update the same service. Additionally, depending upon the level of effort on the Automate side, we may wish to revisit adding state on the Habitat side, bumping up the priority of the supervisor work, etc. Another option would be just using the service update started event on the Automate side without trying to derive any additional information. This needs discussion with the Automate team and Product.
Signed-off-by: Gina Peers email@example.com