Open dustymabe opened 1 year ago
One particular reason this is important is that we typically only do ad-hoc
out of cycle releases when bugs/regressions were introduced. The current behavior means we can't prevent systems with periodic update strategies from booting into the buggy release.
Furthermore their update window might not allow for another update for another period of time, so they'd be on the buggy release for even longer.
I think this is how the state machine was designed. As much work is done upfront so that when the strategy says "go", it's just a simple reboot. Changing this sounds reasonable. E.g. in the worst case, if an update node's metadata changes to a deadend, that should absolutely block finalization and reset the state machine to go back to looking for the next update. In the case where the preferred node changed but the old node is still valid, maybe it should be up to the strategy logic whether swapping them out is permitted. For the periodic strategy, I could see an argument for not allowing it if the next window is in e.g. 10 minutes.
Bug Report
If I have zincati set to only update say on the weekends:
I'd expect that if a new build comes available before my update window happens then my system would delete the pending/staged one and move on to the next one.
For example.. This week we released two
testing
builds.37.20230107.2.0
on Tuesday and37.20230110.2.0
on Thursday. My system saw and staged37.20230107.2.0
on Wednesday. Here is the current status:I would expect that
zincati
would keep checking the update graph and throw away the pending deployment and go straight to the next one if the update graph allowed for it.Environment
Local bare metal
x86_64
machine.Expected Behavior
Pending deployment gets thrown away and newer update gets staged.
Actual Behavior
Pending (older) deployment appears to continue to be staged.
Reproduction Steps
This is hard because it requires the remote update server to be in certain states at different times. In summary:
Other Information