Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Take service readiness into account #5327

Open
christophermaier opened this issue Jul 12, 2018 · 7 comments
Open

Take service readiness into account #5327

christophermaier opened this issue Jul 12, 2018 · 7 comments
Labels
Focus:Supervisor Related to the Habitat Supervisor (core/hab-sup) component Stale Type: Feature Issues that describe a new desired feature

Comments

@christophermaier
Copy link
Contributor

christophermaier commented Jul 12, 2018

This is related to #5326 but somewhat distinct. If health checks can be incorporated into ongoing service state dissemination, they could also be used to gate when the Supervisor broadcasts that it's actually running that service. In other words, we would only introduce new service rumors for services that are healthy and running. This can be particularly useful for services with long startup times, and by extension, the services that depend on them via binds.

Kubernetes does this with their readiness probes.

If we do this, it's also worth considering if it's worth adding a distinct readiness hook.

@mwrock
Copy link
Contributor

mwrock commented Jul 30, 2018

Would/could this also impact rolling updates? I have a use case where it can take severla seconds for a run hook to actually get a service into a properly running state. Currently that means that rolling updates bring everyone down because while the code may be update one at a time, the rolling update does not wait for each member to be available.

Ideally a rolling update should move to the next member (or a member should only be marked updated) once the updated member is healthy.

@christophermaier
Copy link
Contributor Author

@mwrock Yes! I think this should affect rolling updates, too.

@themightychris
Copy link
Contributor

It would be amazing if habitat's lifecycle could remove the need to have sleep loops in any hooks waiting for a service to come up, they usually end up running similar code to the health check

@christophermaier
Copy link
Contributor Author

@themightychris Yup, I think that's the end goal here. The current structure of the code makes that a bit hard, but we've got a pathway to fixing that.

@stale
Copy link

stale bot commented Apr 2, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

@stale stale bot added the Stale label Apr 2, 2020
@christophermaier christophermaier added Focus:Supervisor Related to the Habitat Supervisor (core/hab-sup) component and removed A-supervisor labels Jul 24, 2020
@stale stale bot removed the Stale label Jul 24, 2020
@christophermaier christophermaier added Type: Feature Issues that describe a new desired feature and removed C-feature labels Jul 24, 2020
@stale
Copy link

stale bot commented Aug 13, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

1 similar comment
@stale
Copy link

stale bot commented Oct 15, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

@stale stale bot added the Stale label Oct 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Focus:Supervisor Related to the Habitat Supervisor (core/hab-sup) component Stale Type: Feature Issues that describe a new desired feature
Projects
None yet
Development

No branches or pull requests

5 participants