kubereboot
feat: add rebootDayOfMonth flag
Description:
Add a new rebootDayOfMonth flag to support rebooting on a specific day of the month. Flag takes input 1-31. Input of 0 will disable the flag.
Testing:
Added a new test file tests/kind/testfiles/test_reboot_day.go to show the functionality at work. Here's the output of the testing file:
Testing reboot-day-of-month=15 for all days of the month (dry-run=true)
2025/09/16 17:18:35 Day 1: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:35 Day 2: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:35 Day 3: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:35 Day 4: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:35 Day 5: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:35 Day 6: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:35 Day 7: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:35 Day 8: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 9: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 10: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 11: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 12: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 13: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 14: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 15: Reboot required but dry-run enabled
2025/09/16 17:18:36 Day 16: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 17: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 18: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 19: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 20: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 21: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 22: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 23: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 24: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 25: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 26: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:36 Day 27: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:37 Day 28: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:37 Day 29: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:37 Day 30: Skipping reboot (reboot-day-of-month=15)
2025/09/16 17:18:37 Day 31: Skipping reboot (reboot-day-of-month=15)
Test completed!
Related Issue(s):
Implements #1213
Hello 👋
First, thank you for your contribution.
You might not be aware of the other issues raised in terms of maintenance windows. Don't hesitate to search around our issues and see for yourself.
In a world of continuous deployment, more flexibility in terms of maintenance windows (compared to what we do) is required.
Your use case is therefore very welcomed.
At the same time, this PR doesn't fully express our requirements in terms of maintenance windows.
Which means that in the long run, we'll continue extending the cli flags until it becomes unreadable or the behaviour becomes unexpected.
With the idea of v2 now out of the door, we have an opportunity to build something different.
I believe we need to express maintenance windows differently, in a more flexible way.
Let's say we read a configmap. How would you express at the same time your case, the usual weekly case, and a few other edge cases (like TZ change)?
Here is my opinion:
- have a maintenance start time, according to cronjob spec
- have a maintenance window duration
- have a maintenance reason
- have nodes on which to apply the maintenance.
We could go for a CRD for it, yet we can start with a convention.
My question to you: would you be okay to carry that torch ? How would you express the maintenance windows? Do you believe a crd would be better?
This is a very good use case.
I do like the idea suggested that it could do cronjob spec for start time. However, I could see the use-case for day-of-month restart now. And would love to adopt this change in my environment.
@evrardjp could we incorporate this and then also move in the direction you've suggested? Would be cool to see this added in.
I am neither in favour of adding a feature just to deprecate it nor want to add two ways to do the same thing.
I would rather clarify our interfaces.
Next to that, v2 is our next effort.
Would you consider working on that feature?
I am neither in favour of adding a feature just to deprecate it nor want to add two ways to do the same thing.
I would rather clarify our interfaces.
Next to that, v2 is our next effort.
Would you consider working on that feature?
I would consider it provided I have time to do so.