Open leonnicolas opened 4 months ago
This PR was automatically considered stale due to lack of activity. Please refresh it and/or join our slack channels to highlight it, before it automatically closes (in 7 days).
Would you mind explaining why it mattered for you?
Passing down a context makes sure that when a caller wants to cancel an operation, some function down the line will not block until it returns. Instead it would probably return a context canceled. In practice, when kured received a SIGINT, it can cancel all outgoing requests and finish processing all incoming requests to the metrics server before it exits.
And why did you want to use background context, please?
This is normally the context you use in the "root" of the application. https://pkg.go.dev/context#Background
And why you used oklog?
At the moment kured starts 2 concurrent processes (go threads) in its main function and the metrics server that blocks the main thread forever. If any of the go threads crash, we would continue to run the metrics server. No way to tell the other thread to exit as well and terminate the main thread (or try to restart the crashed thread). oklog's run package just provides one way to manage the life cycle of threads. We could probably use other packages as well. It was just my personal favorite because its API is so slim.
Propagate a context from the main function to wherever it is needed.
Use
github.com/oklog/run
run groups to handle the life cycle of the go routines running the rebooter and metrics server.Ref: https://github.com/kubereboot/kured/issues/234 and https://github.com/kubereboot/kured/pull/808
Signed-off-by: leonnicolas leonloechner@gmx.de