Skip to content

Provide optional upgrade window setting to limit when a plan can run #63

@bashofmann

Description

@bashofmann

Is your feature request related to a problem? Please describe.
It would be great if you could limit the execution of a plan to a specific timeframe, so that the upgrade jobs of a plan can for example only run:

  • between 2am and 4am
  • every Wednesday between 2pm and 6pm
  • ...

Describe the solution you'd like
I was thinking about adding to configurations upgrade-window-start and upgrade-window-length that work similar to the reboot windows in the container-linux-update-operator (https://github.com/coreos/container-linux-update-operator/blob/master/doc/reboot-windows.md).
The configuration flags could be optionally added as annotations to a Node and the system-upgrade-controller would only schedule a Job on this node if the current time is currently within this timeframe.
By adding the configuration to the Node one could easily configure different upgrade windows on different set of nodes within a cluster. A node setting would affect all plans the same way.

Describe alternatives you've considered
Another option would be to add the configuration flags globally to the system-upgrade-controller as environment variables and/or CLI arguments, but this would decrease the flexibility.

In addition the configuration flag could als be set as a field in the spec of a plan, but I'd propose to discuss this independently, because it adds more complexity to the feature:

  • What happens when the upgrade window of a plan conflicts with the upgrade window of Nodes? The plan would never run them.
  • How would an upgrade window setting of a plan interact with a use case where you want to schedule plans in a cron like way? Is this even something that should be supported or is the channel feature a better solution for this use-case?

Because of this I feel starting with adding these settings to Nodes is a good first step, that would already solve a large amount of use-cases.

Additional context
Once we decide on an implementation, I'll be happy to implement it and create a PR for this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions