# Reconfirmation of running reservations **URL:** \ **Category:** Developers\ **Created:** [November 22, 2019, 11:27pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872 "2019-11-22T23:27:52Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![bhroam](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/bhroam/32/20_2.png) [@bhroam](https://community.openpbs.org/u/bhroam)\ **Post date:** [November 22, 2019, 11:27pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/1 "2019-11-22T23:27:52Z")
Currently if a degraded or in-conflict reservation starts running, no attempts to reconfirm it will be made. The reservation will remain short of nodes for its lifetime. I’m making changes to replace nodes of a running reservation. See the following design document that talks about the changes being made to how degraded or in-conflict reservations will be reconfirmed [https://pbspro.atlassian.net/wiki/spaces/PD/pages/1401815043/Reconfirming+degraded+reservations+that+are+running](https://pbspro.atlassian.net/wiki/spaces/PD/pages/1401815043/Reconfirming+degraded+reservations+that+are+running) Bhroam ---
**Author:** ![scc](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/scc/32/234_2.png) [@scc](https://community.openpbs.org/u/scc)\ **Post date:** [November 25, 2019, 7:15pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/2 "2019-11-25T19:15:03Z")
Thanks @bhroam! One very minor comment is that “Changes to how degraded reservations” seems to be an incomplete header. In the " **New workflow of a degraded or in-conflict reservation**" section, is it left purposefully vague as to HOW “PBS will determine the first time the first reservation reconfirmation will be attempted…”? (Same for how/what resv\_retry will be set to in item 3 in the same section). Will there be no way to control how long PBS will wait before attempting to reconfirm a reservation? ---
**Author:** ![bhroam](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/bhroam/32/20_2.png) [@bhroam](https://community.openpbs.org/u/bhroam)\ **Post date:** [November 25, 2019, 7:53pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/3 "2019-11-25T19:53:07Z")
@scc Thanks for reviewing the document. I originally had more information about how the reservations would be reconfirmed. I had a short conversation with @billnitzberg and he suggested I keep it vague and let PBS decide. If we need to expose controls we can. If you feel strongly, I can go back to my original design where the admin explicitly controls the duration between reconfirmation attempts. As a side note, it will make testing easier since we can set the duration short. Bhroam ---
**Author:** ![bhroam](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/bhroam/32/20_2.png) [@bhroam](https://community.openpbs.org/u/bhroam)\ **Post date:** [January 15, 2020, 1:21am UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/4 "2020-01-15T01:21:35Z")
I’m closing in on finishing my implementation of the feature. I had to change the design a little. I found out that it is impossible to reconfirm in-conflict reservations after they run. When reconfirming a running reservation, you keep the nodes that it has and replace the nodes that are down. The problem is that in-conflict reservation’s resv\_nodes is set to the list of nodes they have. The conflicted nodes were removed. It’s too hard to map the select statement to the nodes that are left. Also to help with testing, I changed the attributes a little. Instead of having reserve\_retry\_init which is time the first reconfirmation attempt is made, I have resv\_retry\_time. This attribute is the time between attempts. Now reserve\_retry\_init is deprecated. The first attempt will be made after reserve\_retry\_time seconds after the reservation is first degraded. Bhroam ---
**Author:** ![arungrover](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/arungrover/32/40_2.png) [@arungrover](https://community.openpbs.org/u/arungrover)\ **Post date:** [January 21, 2020, 6:59pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/5 "2020-01-21T18:59:28Z")
Design looks good to me. ---
**Author:** ![agurban](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/agurban/32/67_2.png) [@agurban](https://community.openpbs.org/u/agurban)\ **Post date:** [February 21, 2020, 7:49pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/6 "2020-02-21T19:49:38Z")
I’d prefer it if we could change “reserve\_retry\_time” to “reserve\_retry\_interval”. It’s really an interval, and it’s not too late to make its purpose easier to understand. ---
**Author:** ![arungrover](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/arungrover/32/40_2.png) [@arungrover](https://community.openpbs.org/u/arungrover)\ **Post date:** [June 3, 2020, 7:21pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/7 "2020-06-03T19:21:54Z")
Hi All, I am fixing a reservation bug in PR [https://github.com/openpbs/openpbs/pull/1795](https://github.com/openpbs/openpbs/pull/1795) that will make PBS server log record ‘Y’ in accounting logs every time a degraded reservation is reconfirmed. Since this is change in external behavior, I have updated the “external interface” section of the document to reflect this change. Please have a look and provide comments. Thanks, Arun ---
**Author:** ![agrawalravi90](https://avatars.discourse-cdn.com/v4/letter/a/848f3c/32.png) [@agrawalravi90](https://community.openpbs.org/u/agrawalravi90)\ **Post date:** [June 4, 2020, 7:57pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/8 "2020-06-04T19:57:47Z")
Hi Arun, Just one comment: **\ requestor=Scheduler@ start=\<(new/original) start time\> end=\<(new/original) end time\> nodes=()** Shouldn’t the resvID value be preceded with a key? e.g - “reserve\_ID=\” ---
**Author:** ![arungrover](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/arungrover/32/40_2.png) [@arungrover](https://community.openpbs.org/u/arungrover)\ **Post date:** [June 4, 2020, 8:09pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/9 "2020-06-04T20:09:01Z")
Thanks for reviewing it Ravi. I don’t think we add reserve\_ID for any reservation related accounting logs. It is always been in “`;;`” format. There was a semicolon missing in the line though. I’ve corrected that. ---
**Author:** ![agrawalravi90](https://avatars.discourse-cdn.com/v4/letter/a/848f3c/32.png) [@agrawalravi90](https://community.openpbs.org/u/agrawalravi90)\ **Post date:** [June 4, 2020, 8:09pm UTC](https://community.openpbs.org/t/reconfirmation-of-running-reservations/1872/10 "2020-06-04T20:09:34Z")
Great, looks good to me then, thanks for correcting it.