Maintenance_windows | Checks and reboots

Hallo :waving_hand: !

I am trying to set up a maintenance_window so that updates can be applied (reboot) over the night. The thing that I ran accross (i do not no if this is by design or no) is that IncusOS will no longer check for updates outside of that maintenance window.
If my understanding is correct, that means that both the update check and the apply should occurs during that configured maintenance window.

I configured it the following way but I just want to make sure this is the appropriate way…

config:
  auto_reboot: true
  channel: stable
  check_frequency: 1h
  maintenance_windows:
    - start_hour: 6
      start_minute: 0
      end_hour: 10
      end_minute: 0

Changed auto_reboot to true and check_frequency to 1h to fit that maintenance window.
System timezone is UTC

Cheers

Yeah, that’s the expected behavior.

IncusOS doesn’t have separate download and apply stages, so the updates are both pulled and applied during the window.

It’s something that could in theory be changed now that we support having multiple images for applications too, effectively allowing for the OS image to be downloaded and setup for next boot and then application images to be downloaded and not switched to, but that’s adding even more logic to a reasonably complex part of the codebase.

Understood.
Just want to make sure, with the above configuration (specifically the 1h check frequency), I should not miss an update right ?

I know we used to have some logic issues around that, but I “think” it should be fine now?

@gibmat

I think the maintenance window logic should be behaving as expected; the config posted above should give the desired result of automatically applying updates only during the overnight window.

We do have an open issue to utilize a common scheduling package (Use new scheduling logic for update checks · Issue #767 · lxc/incus-os · GitHub) which would allow us to eliminate a lot of custom code for determining if/when to check for updates. :slightly_smiling_face:

One request if possible regarding the new scheduling package. That would be great if we can say “wait 1 week” after a release to update :sweat_smile:

I know it sounds funny, but based on yesterday’s failed update, that something that would really be beneficial.

Is there a roadmap or ETA on that new scheduling package ?

Keep up the good work !!

The image server holds at most 3 images, so waiting a week to download an image may be problematic as depending on the week, by the time you’ll attempt the download, the image will have expired :slight_smile:

Given just about every update these days also has at minimum some high severity Linux kernel fixes, we generally don’t want to hold onto old images for too long.

We’ve got a bunch of work being done around individual component updates and application version locking and such being done as part of some Operations Center work, so that may bring in some extra flexibility and APIs to IncusOS.

Speaking of, if you’re managing a fleet of IncusOS boxes, Operations Center could be useful for that as you can have it pull the latest stable IncusOS images into a “staging” channel within Operations Center, have some servers set to consume that channel while the rest are on an internal “stable” channel.

When managed by Operations Center, servers never look for updates, instead they wait for the user to trigger an update on a specific server or cluster which then pulls the latest image in the channel that the server/cluster uses.

Interesting alternative. Can a host (IncusOS) run both Incus and Operation Center (and the operation center can manage the local Incus) ?

I am running the Operations Center inside a VM on IncusOS. I think it should be able to manage the host on which it is running and being able to update it. If you run a cluster, then a really cool feature of OC is a rolling update, which, in theory, should prevent you from braking the cluster as a result of update since each cluster member is automatically evacuated before applying the update.

Yeah, it’s pretty common to run it as a VM on Incus. Servers can boot up just fine even if they can’t reach Operations Center.