Thank you for your examples. I think I’m finally getting it.
I’m not sure I like the fact that occurrences will start late. I have two reasons.
First, the user submits jobs that are the full length of the occurrences. We are just setting them up to fail. We will start a job that will be killed at the end of the occurrence.
Second, a long occurrence immediately followed by a shorted occurrence looks like one really long occurrence. The problem is that we kill all running jobs between the two occurrences. There are reasons to do this (e.g., the two occurrences are on different sets of nodes), but I’m not sure users will understand why their jobs were killed while their reservation is still running.
Currently there is only one way a reservation will start late. If the server is down at the start of a reservation, we will start it when the server comes back up. This case is completely out of our control though. The alter case is completely in our control.
So is this case like when the server comes up in the middle of an occurrence? If so, we should do as you suggest. Although we are in the business of skipping occurrences. Do we skip the short occurrence?
I personally think we should skip it.