Use Cases and Requirements (UCR)

Owned by Prakash Varandani
Last updated: Sept 14, 2017
3 min read

forum discussion

PP-662 - Getting issue details... STATUS

PP-663 - Getting issue details... STATUS

PP-906 - Getting issue details... STATUS

PP-703 - Getting issue details... STATUS

PP-701 - 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 the reservation has not already started, and if the reconfirmation on the same nodes fails (due to overlap with another reservation), PBS should consider other nodes (vnodes) for reconfirmation. If this fails, the request will be denied.

    2. For an already running reservation, if extending the reservation would overlap with another reservation the request should be denied.

    3. 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 if the reservation is empty.
      2. The request should be allowed 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.

      1. If the new start time would interfere with an existing high priority calendared event (i.e. another reservation or dedicated time), PBS should try to reconfirm the reservation on another set of nodes (vnodes). If that is not possible, the request shall fail.

  2. For an already running reservation 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. For a reservation that has not started, 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), PBS should try to reconfirm the reservation on another set of nodes (vnodes). If that is not possible, the request shall fail.
  4. It shall be possible to move the end time of a reservation so that it ends sooner.
  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.

    2. If the requested times cause an overlap of a later instance of the standing reservation being modified, the request will be denied.
  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.