-
Notifications
You must be signed in to change notification settings - Fork 33
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
zincati sticks with staged deployments even if newer is available #928
Comments
One particular reason this is important is that we typically only do 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
The text was updated successfully, but these errors were encountered: