Page Comparison

forum discussion

...

1. Visibility - Public
2. Change Control - Stable
3. Synopsis - A new command that will be used for altering reservation attributes.
4. Details - 
   1. The pbs_ralter command will be used to alter an already submitted advance or standing reservation.
   2. In particular, it can be used to change the start time, end time, mail points, mail_list and the reservation's name.
   3. This command can be used to change an advance reservation or the next/current instance occurrence of a standing reservation.
   4. After the change is requested, the change is either confirmed or denied.
   5. On denial of the change, the reservation is left as is.
   6. If the user changes only one of the times (start time or end time) of the reservation, the duration of the reservation will change.
   7. This command can be used by the owner of the reservation or the admin to alter any reservation.
   8. If the reservation has not started and if it cannot be reconfirmed on the same nodes, PBS will attempt to look for another set of nodes before denying the request.
   9. Following options will be supported:
      

      1. Start time modifier: '-R' <start_time>

         1. Specifies reservation's new start time.

         2. This option can be used only when the reservation is not running or is empty i.e. no jobs are submitted to the reservation.

         3. If the change is allowed, reservation will start at the new time specified with this option to pbs_ralter.

         4. The specifications of providing the time are same as pbs_rsub.

      2. End time modifier: '-E' <end_time>

         1. Specifies reservation's new end time.

         2. This option can be used even when the reservation is running and has jobs that are submitted to the reservation.

         3. If the change is confirmed, reservation will end at the new time specified with this option to pbs_ralter.

         4. The specifications of providing the time are same as pbs_rsub.

      3. Interactive option: '-I' <+block_time>.

         1. Specifies interactive mode.

         2. The pbs_ralter command will block, up to <block_time> seconds, while waiting for the reservation's change request to be confirmed.

         3. <block_time> should be positive.

         4. If the change is allowed within <block_time> seconds, pbs_ralter returns with the status “CONFIRMED”, otherwise it returns .

         5. If the change is denied within  <block_time> seconds, pbs_ralter returns with the status “UNCONFIRMEDDENIED”.

         6. If the request cannot be processed within <block_time> seconds, pbs_ralter returns with the status "UNCONFIRMED"

         7. Format: Integer.

         8. Default: Not interactive.

      4. -m <mail_points> 

         1. Works same as pbs_rsub. 

      5. -N reservation_name

         1. Works same as pbs_rsub.

      6. -M mail_list

         1. Works same as pbs_rsub.

   10. For standing reservations if the times requested conflict with any of the later instancesoccurrences, PBS will deny the alter request with appropriate message on the CLI (Interface 7) and a server log (Interface 14).

...

Interface 7: A new error code (number undecided yet) and a new error message for pbs_ralter denoting that a later instance of the the current/next occurrence of a standing reservation being altered will conflict with the instance being alteredinterferes with a later occurrence.

1. Visibility - Public
2. Change Control - Stable
3. Synopsis - As per the requirements, if the instance occurrence of a standing reservation being altered will cause a overlap of any later instance occurrence of the standing reservation being altered, PBS will deny the alter request.
4. Details - When pbs_ralter is used for altering an instance occurrence of a standing reservation, and if the requested times cause a overlap of any later instance occurrence of the standing reservation, this new error code is returned and "pbs_ralter: New timings overlap Requested time(s) will interfere with a later instanceoccurrence" is displayed on the console.

...

1. Visibility - Public
2. Change Control - Stable
3. Synopsis - The 'Y' accounting record does not have any useful information, so it needs to be improved.
4. Details - .
   
   1. When an advance reservation request is confirmed for the first time, 'Y' record will have the format: "Y; <resvID> requestor=Scheduler@<server> start=<requested start time> end=<requested end time> nodes=(<allotted nodes>)".
      
      1. example - "Y; R123.server requestor=Scheduler@svr start=1497264531 end=1497264651 nodes=(node1:ncpus=3)"
   2. When a standing reservation request is confirmed for the first time, 'Y' record will have the format: "Y; <resvID> requestor=Scheduler@<server> start=<requested start time> end=<requested end time> nodes=(<allotted nodes>) count=<count>". The nodes field will be specific for the first instanceoccurrence.
      
      1. example - "Y; R123.server requestor=Scheduler@svr start=1497264531 end=1497264651 nodes=(node1:ncpus=3) count=3"
   3. This record will be written when an advance reservation alter request is confirmed. The log will have the same format as in point 'a' above, but the requested field(s) will be updated with new value(s): "Y; <resvID> requestor=Scheduler@<server> start=<(new/original) start time> end=<(new/original) end time> nodes=(<allotted nodes>)".
      1. example - "Y; R123.server requestor=root@hostname start=1497264471 end=1497264651 nodes=(node1:ncpus=3)"
   4. This record will be written when a standing reservation alter request is confirmed. The log will have the same format as in point 'b' above, but the requested field(s) will be updated with the new value(s) and index of the next instance occurrence will be appended. The nodes field will be specific for the instance occurrence altered: "Y; <resvID> requestor=Scheduler@<server> start=<(new/original) start time> end=<(new/original) end time>  nodes=(<allotted nodes>) count=<count> index=<index of the altered instance>occurrence>".
      1. example - "Y; R123.server requestor=root@hostname start=1497264471 end=1497264651 nodes=(node1:ncpus=3) count=3 index=1"

...

1. Visibility - Public
2. Change Control - Stable
3. Synopsis - Event type - Reservation, log level - Info.
4. Details - 
   1. When an advance reservation is confirmed, server logs this event.
      
      1. This log will have the format: "Resv;<ResvID>;Reservation confirmed".
   2. When a standing reservation is confirmeddenied, server logs this event.
      
      1. This log will have the format: "Resv;<ResvID>;Reservation denied".

Interface 15: A new server log when the requested timings of an instance the current/next occurrence of the standing reservation being altered would cause an overlap of interfere with a later instance occurrence of the standing reservation being altered, and the request is denied.

1. Visibility - Public
2. Change Control - Stable
3. Synopsis - Event type - Reservation, log level - Info.
4. Details - 
   1. The log will have the format - "Resv;<ResvID>;The requested times would overlap time(s) would interfere with a later instanceoccurrence"

Interface 16: A new PBS IFL API for modifying a reservation.

...