Creation of BookingScheduler resource

Why

Since the release of the cost-saving app, we have needed a way to make bookings recurring and with that provide flexibility and automation to the users. In the last weeks, we got questions about the possibility to easily make bookings on a given schedule, which gives us a perfect moment to finally implement this.

How

We agreed that we'll use the Kubernetes cronjob/job relation as an inspiration. Meaning that we'll create a new resource BookingScheduler which will be able to create bookings on a given schedule.
Note that bookings are still the only object that controls wether a resource should be reserved or not. The BookingScheduler is just a creator of bookings, with some extra options to control when and for how long a booking should be created.

Fields

• schedule — A string in the crontab format which will be used to schedule reconciliation and with that — creation of bookings on a given date time. Since it is used internally by Kubernetes for their cronjob implementation, the plan is to use cron for parsing it to a next date time.
• duration — We need a field to store how long the booking should be. For now, I suggest we use minutes for it. So, a 2-hour booking will have duration: 120.
• template / bookingTemplate — Where we place the booking spec fields. Taking direct inspiration from how deployments and other resources that have it. Supposedly this will make things more maintainable as we won't have to sync or duplicate resource fields between the scheduler and the booking. I don't think there are many suggestions out there on how to do it, so we'll experiment. My first try would be to directly point the template field to the booking spec struct.

Logic Flow

0. Create the BookingScheduler with the given schedule and a duration.
1. The creation triggers the reconciliation function.
   1. Create the booking based on the given params.
   2. Parse the schedule using the current time (ex. now.next(cron), which gives us the next date time a booking should be created.
   3. Use that date time to queue the next reconciliation of the booking scheduler. Return a queue object with a value in minutes that is basically the next occurrence — now, in minutes.
2. On the next reconciliation, the process continues from step 1.1

Possible issues to have in mind

We discussed these in a more detailed document and we agreed on possible solutions to try, so to keep things short I'll just mention the highlights so we have then in mind when working on this.

• Possible execution delay
• Duplicating booking fields makes things hard to maintain
• How modifying the BookingScheduler should affect the bookings.

Changes to Booking

• OwnerReferences — Pointing scheduled bookings to a BookingScheduler will allow us to properly manage the effects in case of a state change or deletion of the BookingScheduler.