[RFE] [SSM] Sliding schedule co-term window dependent by date/time of week in schedule start

[sadsfae]

Scenario to Solve

The current value via ssm_default_lifetime: in conf/selfservice.yml controls a configurable value for the total maximum amount of time a self-scheduled assignment will live.

However we don't want self-scheduled assets to conflict with deliberate scheduled workloads and a self-scheduling request later in the week could potentially push past our preferred Sunday 22:00 automation assignment/reclamation process.

Solution: Configurable Sliding Window Dependent on Submission Day-of-week

• The maximum time is set via ssm_default_lifetime (5 days in our case) but as the week progresses you get the later window of that 5 days so nothing runs beyond Sunday at 21:00

Implementation Approaches

• We want this to be configurable option because some new QUADS adopters may not even have a preferred day-of-week for deliberate scheduling activities and simply always want to honor ssm_default_lifetime:

This would ultimately end up with something like this given a 5-day SSM lifetime:

Sunday/Monday = 5 days
Tuesday = 5 days
Wednesday = 4 days
Thursday = 3 days
Friday = 2 days
Saturday = 1 day (or until Sunday at 21:00)
Sunday = until 21:00

• Below are initial ideas on how to implement this via configurable settings in conf/selfservice.yml

Design Implementation

• Automatic handling of backend --schedule-end expiration window co-term:

(management values in https://github.com/redhat-performance/quads/blob/development/conf/selfservice.yml )

• ssm_enable_sched_window: true/false (default is false)
• ssm_deadline_day: mon/tue/wed/thu/fri/sat/sun (default is sunday)
• ssm_deadline_hour: 21:00

If this is true then we can carry the calculation to split the integer value of ssm_default_lifetime from when the SSM schedule was entered until the number of days until ssm_deadline_day. For example if a self-schedule was entered on Saturday it will only run until a maximum of Sunday at 21:00 given the above settings.

One way we could implement this on the backend is --schedule-end is calculated based on the --schedule-start entered via the SSM API backend workflow. We can use a full 24hours from the day the schedule is entered for the HH:mm for --schedule-end unless it lands on a Sunday in which case it's always the value of ssm_deadline_hour

Perhaps a simpler way to implement this is just automatically terminate any running self-scheduled assignment that would exceed these values.

• ssm_deadline_day: sun
• ssm_deadline_hour: 21:00

However I think it is likely cleaner to calculate the --schedule-end date/time initially at the start of when the assignment is entered based on where it would land within the window range of ssm_default_lifetime

Organic Additional Solution: Self-terminate when done

• In general tenants should be self-terminating their assignment when they are done anyway and this is available for the API and should be mandatory for automated self-scheduled requests (e.g. CI etc).

[sadsfae]

FYI @josecastillolema @jtaleric @abondvt89 I heard this mentioned on the CPT recording, this is something we have already discussed before but put it an RFE.