Use Cases and Requirements (UCR)

forum discussion

PP-662 - Getting issue details... STATUS

PP-663 - Getting issue details... STATUS

A. Use Cases:

1. There is a possibility that the input required for the job(s) in a reservation arrive late and so the job cannot start. The reservation would start at its scheduled time and the resources reserved for it would be underutilized. So, the admin would like to have the reservation start at a later time.
2. If a reservation job(s) starts late or is taking longer than expected, there is a possibility that it would run past the end time of the reservation. Admin would like to extend the end times of a reservation.

   1. If extending the reservation would overlap with another reservation the request should be denied.

   2. In order to extend the current reservation it may be necessary for the admin to manually push back the start time of a following reservation.

3. There is a possibility that the input required for the job(s) in a reservation arrive earlier than expected. The admin would like to be able to move the start time of the reservation forward so that the job(s) can start sooner.

4. If the job is done sooner then expected the admin would like to be able to move the end time of the reservation forward to free up the resources.

5. It would be nice to be be able to automatically decide what to do should a job or jobs still be running at the end of a reservation -

   1. Kill job(s).

   2. Extend end time of the reservation.
   3. Requeue the jobs.
   4. Hold the jobs.

B. Requirements:

1.  It shall be possible to move the start time of a reservation.

   1. It shall be possible to push the start time into the future.

      1. The request should be allowed only if the reservation is empty.
      2. The request should be allowed only if the reservation has not already started.

   2. It shall be possible to move the start time of a confirmed reservation sooner if resources are available.

2. It shall be possible to extend the end time of a reservation.

   1. If the new end time would interfere with an existing high priority calendared event (i.e. another reservation or dedicated time) the request shall fail.

3. It shall be possible to move forward the end time of a reservation so that it ends sooner.
4. While changing the times of a reservation, if the reconfirmation on the same nodes fails, PBS should consider other nodes (vnodes) for reconfirmation.
5. A new CLI viz. pbs_ralter to be provided so alter the reservation.

6. The new capabilities should be applicable on advance reservations.

7. The new capabilities should be applicable on standing reservations.

   1. The instances of the standing reservation that need to be modifiable are the current and next one.

8. A scheduling cycle should also be triggered by the end of an advance reservation.

C. Future (or nice to have) requirements:

1. There shall be a “force” option that would allow an operator or manager to extend the reservation even if it were to overlap with a calendared event.

2. It shall be possible to have a reservation attempt to automatically extend it’s end time until any running jobs in the reservation finish given the restriction in B.2.a

3. When extending the end time of a reservation it shall be possible for any unused nodes in the reservation be freed.

4. It would be nice to have a hook execute at the end of a reservation so that an admin can automatically control what happens to any jobs still running in that reservation. For example, the admin may want to:

   1. Kill the job (existing behavior).

   2. Extend end time of reservation.

   3. Requeue the jobs.

   4. Hold the jobs.

5. Provide an index format to specify a particular instance of a standing reservation.