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 the Daemon started the overlord.Loop(). The current restriction stems from the fact that state.EnsureBefore() adjusts the ensure timer expiry time, and the timer is only created when overlord.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 their Ensure() method as an indication the overlord loop was entered, which is unnecessary manager boilerplate code. See overlord/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.