-
Notifications
You must be signed in to change notification settings - Fork 54
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
fix(overlord): allow ensure when state is available #482
Conversation
1326060
to
7103bb8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my input
327e7f5
to
f888c6d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you, especially for the added comments
53edc87
to
59c065e
Compare
59c065e
to
6d06635
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
@dmitry-lyfar Just a quick check that you are fine with this, and knows about this tweak ? |
@flotter thanks, having comments there is great. I see no issues with this. |
Managers can explicitly call
state.EnsureBefore()
if they wish to apply changes sooner than the scheduled 5min ensure overlord timer.Although managers get a state instance at creation time, during
overlord.New()
, it is currently forbidden to call ensure early on before theDaemon
started theoverlord.Loop()
. The current restriction stems from the fact thatstate.EnsureBefore()
adjusts the ensure timer expiry time, and the timer is only created whenoverlord.Loop()
is called.The problem:
Since the overlord ensure loop is only started later on during
daemon.Start()
, a manager has no direct way to know when it's safe to call Ensure. Managers currently have to use the first call to theirEnsure()
method as an indication the overlord loop was entered, which is unnecessary manager boilerplate code. Seeoverlord/checkstate/manager.go
.Managers (and managers with dependencies on other managers), may want to implement state changes during callbacks. These events can come from outside the overlord framework (e.g. from the Linux kernel or early on during manager
StartUp
), meaning that handlers using state may be triggered asynchronously from the Daemon startup sequence, and arrive before the overlord Loop is started.Solution:
Allow
state.EnsureBefore()
to be called before the timer exists. Since an implicit ensure is performed on overlord loop entry, simply returning while the timer does not exist is the same as saying an ensure is already scheduled.