periodic windows with fleet_lock

[sgohl]

Feature Request

As I understand the docs -> https://github.com/coreos/zincati/blob/main/docs/usage/updates-strategy.md, it is only possible to decide for one of both strategies.

The problem:

Even highly available services encounter a little service disruption from client side, as load-balancers like HAProxy, Traefik, or pacemaker, whatever, take their second to failover, remove the node, redistribute requests etc, as healthchecks aren't likely to be set to milliseconds everywhere, resulting in some requests hitting the wall within some seconds.
It may sound neglectable, but in some situations, it really isn't.

Desired Feature

What I need: Periodic windows with fleet_lock

Only fleet_lock is not enough, since I only want to apply upgrades in certain time-windows.
Only periodic is not enough, because without fleet-lock it possibly reboots two HA nodes at the same time.

Example Usage

[identity]
rollout_wariness = 1.0
group = "default"

[updates]
strategy = "periodic_fleet_lock"

[[updates.periodic.window]]
days = [ "Sun" ]
start_time = "01:30"
length_minutes = 60

[updates.fleet_lock]
base_url = "http://1.2.3.4:3333/"

Adding a new option like periodic_fleet_lock that could work in the way it respects the time-frames and apply the fleet_lock strategy would be awesome, and also be backwards-compatible

Although, there mere fact that the option [updates.fleet_lock] exists, should be a sufficient indication that it should acquire a pre-reboot request.

What you think? :-)

[craigcabrey]

I also had this use case. I proposed a change to Fleetlock itself but was rejected due to wanting to keep the locking logic simple (which is fair).

[sgohl]

As I read your comment, I'm concluding it's actually not a fleet lock issue, but rather a feature request for zincati.
To make my initial request more clear, I don't talk about the Download and Staging part of the upgrade, rather than the apply by rebooting.

So, although I talked about fleet lock, I actually mean: Zincati should be able to respect a configured time-frame for the actual reboot which then is handled with a fleet lock

hope that makes sense

[craigcabrey]

Agreed, I would like to see time window in Zincati (as it's currently implemented for at least one other mode). I have a fork of Fleetlock that adds a basic maintenance window as a stopgap.

[bitfisher]

A combination of fleet_lock and periodic strategy would be a very useful feature!

[sgohl]

I just came to the conclusion that the following descriptive configuration should do what you actually suppose:

[identity]
rollout_wariness = 1.0
group = "default"

[updates]
strategy = "fleet_lock"

[updates.fleet_lock]
base_url = "http://airlock:3333/"

[[updates.fleet_lock.window]]
days = [ "Mon" ]
start_time = "01:00"
length_minutes = 60

What translates to: update/reboot/finalize is allowed in the configured timeframe using with fleet_lock

there is no documentation whether updates.fleet_lock.window exists or not, nor does the systemd-service moan about it:

zincati[27626]: [INFO  zincati::strategy] update strategy: fleet_lock
systemd[1]: Started zincati.service - Zincati Update Agent.
[INFO  zincati::update_agent::actor] reached steady state, periodically polling for updates
[INFO  zincati::cincinnati] current release detected as not a dead-end

I think, https://coreos.github.io/zincati/usage/updates-strategy/#lock-based-strategy should mention if/if not it's possible to use a time-window with fleet_lock

If not, I'm curious if it could be implemented?

[jlebon]

Not sure about this. The fleet lock strategy is already intended to allow update schemes as complex as you'd like by pushing your business logic to the service. I can appreciate that this then passes the buck to whatever popular fleet lock implementation one is using.

I think we could make it easier for people to plug in their desired logic. E.g. we could have a basic/skeleton implementation that is meant to be forked off and filled in with one's own logic?

[bitfisher]

As maintenance windows are a very common requirement, fleet_lock.window would be the most basic implementation, Zincati should provide.

It does so already for periodic updates!

And probably most users would be happy with that implementation!

Or separate updates from reboot coordination so one can use periodic in combination with fleetlock?