You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I'd like:
Bottlerocket nodes currently decide for themselves when an update "becomes visible" to the host. This is controlled by a combination of the following factors:
The node's update seed which determine's its position in the wave schedule
The node's ignore-waves setting, which allows the node to op to ignore the wave schedule.
It would be useful if we could add an additional setting to add an arbitrary delay to the update.
As an example, suppose we introduce a new setting:
apiclient set settings.updates.delay="48 hours"
Instead of using the settings.updates.seed value to make the update available exactly when that node's position becomes "ready" in the wave schedule, we would use the relevant wave's start time + the offset dictated by the new value.
We may be able to retrofit this setting into settings.updates.ignore-waves so that string values indicate the delay:
This is something that could also be implemented in the update agents (e.g. brupop). I'm not as inclined to prefer this, since it would only solve the problem for a subset of Bottlerocket users which use in-place updates.
The text was updated successfully, but these errors were encountered:
After some further discussion, I think two unique settings may be less ambiguous:
The existing boolean ignore-waves
A new setting, delay-waves or bake-time.
The semantics would be as such:
If ignore-waves is true, wait for the static bake-time but always delayed from the very first wave in the update schedule (or perhaps based on the update publication day).
If ignore-waves is false, wait for the static bake-time but delayed from the wave position that the node would have otherwise fallen under.
What I'd like:
Bottlerocket nodes currently decide for themselves when an update "becomes visible" to the host. This is controlled by a combination of the following factors:
It would be useful if we could add an additional setting to add an arbitrary delay to the update.
As an example, suppose we introduce a new setting:
Instead of using the
settings.updates.seed
value to make the update available exactly when that node's position becomes "ready" in the wave schedule, we would use the relevant wave's start time + the offset dictated by the new value.We may be able to retrofit this setting into
settings.updates.ignore-waves
so that string values indicate the delay:Any alternatives you've considered:
This is something that could also be implemented in the update agents (e.g. brupop). I'm not as inclined to prefer this, since it would only solve the problem for a subset of Bottlerocket users which use in-place updates.
The text was updated successfully, but these errors were encountered: