Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

forum discussion

PP-662 - Getting issue details... STATUS

PP-663 - Getting issue details... STATUS

Interface 1: A new CLI pbs_ralter.

  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 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, pbs_ralter returns with the status “CONFIRMED”, otherwise it returns with the status “UNCONFIRMED”.

        5. Format: Integer.

        6. 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 new end time requested conflicts with any of the later instances, PBS will try to confirm the instance on another set of nodes, and if not possible, will deny the alter request. In this case, the next instance of the reservation will start only after the altered reservation finishes.
      1. example: 
        # pbs_rsub -R 1000 -E 1100 -r "FREQ=HOURLY;COUNT=3" -I 8
        S100.server CONFIRMED
        # pbs_ralter -E 1130 S100 -I 8
        S100.server CONFIRMED (pbs_rstat -f will show another set of nodes allocated to this instance).
        In the above example, the second instance will start running at 11:30 which is after the first instance finishes running. 
        All the jobs that were running in the first instance will be deleted.
    11. For standing reservation if the new start time is after the last instance of the standing reservation, only the altered instance will be able to run (if alter is successful) and other instances will be skipped as the other instances will have their end times in the past by the time the altered reservation finishes running.
      1. example:
        # pbs_rsub -R 1000 -E 1100 -r "FREQ=HOURLY;COUNT=3" -I 8
        S100.server CONFIRMED
        # pbs_ralter -E 1300 S100 -I 8
        S100.server CONFIRMED
        In the above example, the second and third instance of the reservation will be getting skipped.
    12. For standing reservation if the new start time of the current/next instance is after end time of the nth instance of the standing reservation, the altered instance will be able to run (if alter is successful), but the instances between the current/next and the nth instance will be skipped as these instances will have their end times in the past by the time the altered reservation finishes running.
      1. example:
        # pbs_rsub -R 1000 -E 1100 -r "FREQ=HOURLY;COUNT=3" -I 8
        S100.server CONFIRMED
        # pbs_ralter -E 1200 S100 -I 8
        S100.server CONFIRMED
        In the above example, the third instance of the reservation will be getting skipped.

Interface 2: CLI response message displayed when a reservation alter could not be confirmed within block_time for interactive option.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - A new CLI response message denoting that the alter request for a reservation could not be confirmed within the block_time provided while using the interactive option of pbs_ralter command.
  4. Details - While using the interactive option, the pbs_ralter command blocks up to block_time seconds while waiting for the reservation's change request to be confirmed. There is a possibility that the request could not be processed within block_time seconds. In that case the command line returns and "pbs_ralter: <resvID> UNCONFIRMED" is displayed on the console.

Interface 3: CLI response message displayed when a reservation alter request is confirmed within block_time for interactive option.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - A new CLI response message denoting that the alter request for a reservation was confirmed within the block_time provided while using the interactive option of pbs_ralter command.
  4. Details - While using the interactive option, the pbs_ralter command blocks up to block_time seconds while waiting for the reservation's change request to be confirmed. If the request is confirmed within block_time seconds, the command line returns and "pbs_ralter: <resvID> CONFIRMED" is displayed on the console.

Interface 4: CLI response message displayed when a reservation alter request is denied within block_time for interactive option.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - A new CLI response message denoting that the alter request for a reservation was denied. Displayed when the interactive option of pbs_ralter command is used.
  4. Details - While using the interactive option, the pbs_ralter command blocks up to block_time seconds while waiting for the reservation's change request to be confirmed. If the request is denied within block_time seconds, the command line returns and "pbs_ralter: <resvID> DENIED" is displayed on the console.

Interface 5: CLI response message displayed in non-interactive mode of pbs_ralter.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - A new CLI response message denoting that an alter request for a reservation is being made.
  4. Details - While using the non-interactive option, the pbs_ralter command returns immediately "pbs_ralter: <resvID> ALTER REQUESTED" is displayed on the console.

Interface 6: A new error code (number undecided yet) and a new error message for pbs_ralter denoting that a non-empty reservation that has already started running cannot have its start time altered.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - As per the requirements, reservation in RUNNING state cannot have its start time altered if there are jobs in it.
  4. Details - When pbs_ralter is used for altering its start time that has jobs in it and has already started running, this new error code is returned and "pbs_ralter: Reservation not empty" is displayed on the console.

Interface 7: A new reservation state denoting that it is being altered (short format).

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - When a reservation alter is being requested in non-interactive mode, until the scheduler confirms/denies the change, the reservation will switch to a new state.
  4. Details - 
    1. When using non-interactive mode of pbs_ralter, the user who has requested the change can check the status of the request by using pbs_rstat. After the request is made, and until the PBS scheduler confirms/denies the change, the reservation will switch to a new state "AL" denoting that it is being altered.
    2. When using non-interactive mode of pbs_ralter, the user who has requested the change can check the status of the request by using pbs_rstat -f. After the request is made, and until the PBS scheduler confirms/denies the change, the reservation will switch to a new state "RESV_BEING_ALTERED" denoting that it is being altered.

Interface 8: Improvement to the 'Y' accounting log.

  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 instance.
      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 will be appended. The nodes field will be specific for the instance 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>".
      1. example - "Y; R123.server requestor=root@hostname start=1497264471 end=1497264651 nodes=(node1:ncpus=3) count=3 index=1"

Interface 9: Improvement to the 'U' accounting log.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - The 'U' accounting record will now have recurrence rule and timezone information for a standing reservation. 'U' record for advance reservation remains unchanged.
  4. Details - .
    1. When a standing reservation is submitted, the 'U' record will now have the format: "U;S56.d_server;requestor=pbsuser@d_server recurrence_rrule=FREQ=HOURLY;COUNT=2 timezone=Asia/Kolkata".
      1. example - "U;S56.d_server;requestor=pbsuser@d_server recurrence_rrule=FREQ=HOURLY;COUNT=2 timezone=Asia/Kolkata"

Interface 10: A new server log denoting that a reservation alter is being attempted.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - Event type - Reservation, log level - Info.
  4. Details - When a reservation alter is being requested, the PBS server attempts to get a confirmation from the PBS scheduler.
    1. If only start time is being changed, this log will have the format: "Resv;<ResvID>;Attempting to modify reservation start=<requested start time>".
      1. example: "Attempting to modify reservation <resvID> start=1497264471"
    2. If only end time is being changed, this log will have the format: "Resv;<ResvID>;Attempting to modify reservation end=<requested end time>".
      1. example: "Attempting to modify reservation <resvID> end=1497264711"
    3. If both times are being changed, this log will have the format: "Resv;<ResvID>;Attempting to modify reservation start=<requested start time> end=<requested end time>".
      1. example: "Attempting to modify reservation <resvID> start=1497264471 end=1497264711"

Interface 11: A new server log denoting that a reservation alter request is denied/confirmed.

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

Interface 12: A new server log providing information on a newly submitted reservation.

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - Event type - Reservation, log level - Info.
  4. Details - 
    1. When an advance reservation is submitted, server logs this event.
      1. This log will have the format: "Resv;<ResvID>;New reservation submitted start=<requested start time> end=<requested end time>".
    2. When a standing reservation is submitted, server logs this event.
      1. This log will have the format: "Resv;<ResvID>;New reservation submitted start=<requested start time> end=<requested end time> recurrence_rrule=<rrule> timezone=<timezone>".

Interface 13: A new server log when a reservation is confirmed/denied.

  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 confirmed, server logs this event.
      1. This log will have the format: "Resv;<ResvID>;Reservation denied.".

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

  1. Visibility - Public
  2. Change Control - Stable
  3. Synopsis - New IFL API.
  4. Details - 
    1. Signature - 

      char * pbs_modify_resv(int server_connect, char *resv_id, struct attropl *attrib, char *extend)

      1. server_connect - socket on which we connect to the server.

      2. resv_id - reservation ID.
      3. attrib - list of attributes to be changed.
      4. extend - for future extensions.
  • No labels