Skip to content
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

config: add reboot_window for datetime constrained reboots #13

Open
lucab opened this issue Jun 12, 2019 · 4 comments
Open

config: add reboot_window for datetime constrained reboots #13

lucab opened this issue Jun 12, 2019 · 4 comments

Comments

@lucab
Copy link
Contributor

lucab commented Jun 12, 2019

Airlock needs to have additional knobs to configure a "maintenance window" for reboots. Those needs to added both for the default group, and for specific custom groups.

A reboot window works in conjunction (logical AND) with existing counting-semaphore logic.

Entries to be added to the lock section:

  • default_reboot_window_days: a set of short-day-names (like date %a, i.e. [ "Mon", "Wed" ])
  • default_reboot_window_start: start time, in 24h format (i.e. 23:45)
  • default_reboot_window_duration: length, in minutes

Entries to be added for each lock.groups section (these override defaults, if set):

  • reboot_window_days
  • reboot_window_start
  • reboot_window_duration

Note: this relies on the system clock of the environment where an airlock process is running.

@arithx
Copy link

arithx commented Jun 12, 2019

Should the window_start also include a timezone indicator and/or another variable specifying it? It seems reasonable that I might want to do all reboots within a specific timezone independent window (e.x. between 00:00 & 06:00 UTC) on a fleet of nodes that might be in multiple time zones.

@lucab
Copy link
Contributor Author

lucab commented Jun 12, 2019

TZ topic gets tricky quickly (countries changing the TZ they are in, TZ being redefined through the year, daylight-saving being a different TZ label, daylight switching). And I think locksmith was pretty much unaware of all of that (but I'd need to double check).

I don't have a good solution here. Perhaps one of these two approaches could work:

  1. always use UTC (this likely works better in containers without tzdata file and TZ env)
  2. always use local time (this is easier to reason about as a human, but depends on correct environment config, and can trip-off people in distributed environments)

Sidenote, if the environment is properly configured for UTC, option 2 could be seen a more complex/rich way to achieve option 1.

@arithx
Copy link

arithx commented Jun 12, 2019

Maybe default to UTC and have a flag for using local time?

@lucab
Copy link
Contributor Author

lucab commented Jan 21, 2021

For reference, this is the set of configuration knobs we added to Zincati: https://coreos.github.io/zincati/usage/updates-strategy/#periodic-strategy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants