Ability to define schedule for bundles

[ibrokethecloud]

The PR introduces schedule and scheduleWindow fields in the cluster.fleet and bundle crd's.

This allows users to define a cron based schedule and a schedule window at the bundle or cluster level.

If a schedule exists at the cluster level, then the schedule is applied to all bundles in scope for the said cluster. The cluster level schedule takes precedence of bundle level schedule if there is one.

The user can add a schedule and window to the cluster as follows:

apiVersion: fleet.cattle.io/v1alpha1
kind: Cluster
metadata:
  name: c-kd88w
  namespace: fleet-default
spec:
  clientID: 5n7ddd4ftxmwg5nd4zm4j99kcgdtjz9fq8cbv9pqxxfmqlgcptv65n
  kubeConfigSecret: c-kd88w-kubeconfig
  paused: false
  redeployAgentGeneration: 3
  schedule: 05 03 * * *
  scheduleWindow: 10m

Similarly a schedule and window can also be defined at the bundle level too.

namespace: default
schedule: "30 13 * * *"
scheduleWindow: "5m"
helm:
  releaseName: labels
  values:
    clusterName: global.fleet.clusterLabels.management.cattle.io/cluster-display-name
diff:
  comparePatches:
  - apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    name: labels-fleetlabelsdemo
    namespace: default
    jsonPointers:
    - "/spec"

Once the bundle has been processed by the fleet controller, the downstream cluster's fleet agent will honor the scheduling of the said bundle deployment and deploy the same.

The scheduleWindow allows us to handle use cases where the fleet agent may be disconnected for any reason.

This allows for the downstream cluster to still process the bundle as long as the reconnect time falls within the schedule + scheduleWindow.

If the cluster fails to reconnect, the bundle will get rescheduled.

Related to: #383

[cloudnautique]

@ibrokethecloud is there a concept of a maintenance window? If a user wants to specify that clusters can be updated between midnight and 5 AM for example? Could a combination of wild cards and a Window be used?

Also, will the fleet yaml bundles allow for target overrides?

[ibrokethecloud]

Hi @cloudnautique there are two main items here.. The cron schedule, at which time the downstream cluster will try and process the bundle. Since the bundle deployment is processed by downstream cluster, there are cases where the cluster may be unable to reach the Rancher master for the bundle deployments. In that case the scheduleWindow kicks in. The idea is that if the downstream cluster connects back within the Start Time (schedule) + scheduleWindow , the bundle will still be processed. This should help manage use cases where there may be a change window, and cluster may be down for other changes.

The user can specify the schedule and scheduleWindow at the cluster or bundle level. If a schedule and scheduleWindow are present on the cluster, then all bundles being applied to this cluster will be applied using this spec. Any bundle level schedule and scheduleWindow will be overridden. The idea is that the cluster admin would be able to define the schedule and window at the cluster level, and may be we dont want a developer to apply a bundle outside this schedule + window combo.

If there are no cluster specific schedule and scheduleWindow then the users can specify the same at the bundle level, and again apply target specific overrides for schedule and scheduleWindow too.

[philomory]

Is there any possibility of this PR being reviewed? This functionality was originally scheduled to go into Rancher 2.6 (so, Fleet 0.3.6), but, that milestone was removed from the associated issue, and this PR hasn't had any movement in a few months.

[nickgerace]

We should put this in the Helm chart.

[ibrokethecloud]

@nickgerace do you want to expose this default Window as an option for the agent controller? similar to checkin interval?

[nickgerace]

Yes!

[nickgerace]

@StrongMonkey we should get this into next release.

[nickgerace]

@ibrokethecloud it appears that we have conflicted based on merging your other PRs recently.

[ibrokethecloud]

@nickgerace i have rebased changes from master. May need a hand to kick off the failed CI step again.

[gravufo]

Any news on a timeline to merge this PR?

[Athosone]

Hi,

There is a duplicated error check here