[SURE-7780] Simple scheduling of GitOps deployments

[weyfonk]

Notes from discussion:

Implementation:

• no new bd by bundle reconciler unless in schedule (add state for skipped in status?)
• update "inSchedule" field on cluster (quartz/cron), quartz job acts on crd, toggles inSchedule
• new field "inSchedule" so we don't run into conflicts with paused
• cluster updates, triggers bundler reconciler, creates bd, agent installs it
• separate Schedule CRD for crontabs
  • less checks when evaluating windows
  • fields:
    • cluster selector, gitrepo selector
    • schedule: {crontab, duration}?
  • detect overlaps?
• very similar to cluster.spec.paused and rollouts

---

History on this includes PRs #450 and #727, both outdated, and issue #383.

The current idea is to support simple, crontab-like syntax for scheduling deployment of workloads.

Scope

This applies to GitOps deployments. HelmOps is not covered at this point.

Assumptions

• A git repository referenced by a GitRepo/bundle with scheduling enabled should not be polled before the scheduled start time

  • In turn, this means that the gitOps controller would be responsible for enforcing scheduling:
    • Delaying polling of the git repository and creation of a job cloning the git repository and creating bundles until the next scheduled start time
    • Updating the GitRepo's status to something like Scheduled, perhaps stating the next scheduled start time

• Pausing should still have precedence over scheduling; as per the previous point, enforcing that precedence at GitRepo level should be sufficient

Open questions

• Where should this configuration be applied? Should it be at cluster or even cluster group level, with options to override it at GitRepo or even bundle deployment (through target customisations) levels?
  • Configuring this should be possible at least at GitRepo level; future iterations could add cluster or cluster group-level config and target customisation support, with easy migration paths for users:
    • When target customisations are added: updating fleet.yaml files to use them
    • When cluster or cluster group support is added (with overrides at lower levels): configuring cluster/cluster group scheduling, which would still be overridden at lower levels (GitRepo, target customisations) until removed from such levels if needed

Follow-ups (for future iterations):

• Apply commits one by one even if all have been pushed before the scheduling start time
  • Example: upgrade of a chart across multiple minors, none of which should be skipped
  • This should probably be made configurable, to limit the number of deployments when such a precaution is not necessary
  • Could the git job iterate over commits since the latest deployed one, and create bundles, deploy them, and wait for them to be ready for each such commit? This could prevent the monitored git repository from having to be cloned once per commit.
• Extend this feature to HelmOps