labgrid icon indicating copy to clipboard operation
labgrid copied to clipboard

release --kick doesn't clean the reservations table

Open ElenaGrigore opened this issue 2 years ago • 1 comments

Hi,

I have below scenario:

  1. user1: makes a reservation for a board
  2. user1: lock the board
  3. user2: release --kick the board

After step 3 , the board is not acquired by anyone , but it can be re-acquired/locked only by user1 because the reservation table still keeps a record of allocated for that place to user1 - is this the wanted behavior? Shouldn't kick be more aggressive and also clean the reservation?

and with the commands/output: user1: makes a reservation for a board:

(venv) user1@ws1:~/work$ labgrid-client reserve --wait name=RO--MX6Q_sabresd--2
Reservation 'UYOHFZXX2A':
  owner: workstation1/user1
  token: UYOHFZXX2A
  state: allocated
  filters:
    main: name=RO--MX6Q_sabresd--2
  allocations:
    main: RO--MX6Q_sabresd--2
  created: 2023-07-28 14:41:28.345891
  timeout: 2023-07-28 14:42:28.346233
Waiting for allocation...
(venv) user1@ws1:~/work$ labgrid-client  reservations
Reservation 'UYOHFZXX2A':
  owner: workstation1/user1
  token: UYOHFZXX2A
  state: allocated
  filters:
    main: name=RO--MX6Q_sabresd--2
  allocations:
    main: RO--MX6Q_sabresd--2
  created: 2023-07-28 14:41:28.345891
  timeout: 2023-07-28 14:42:28.407206
(venv) user1@ws1:~/work$ labgrid-client who | grep RO--MX6Q_sabresd--2
(venv) user1@ws1:~/work$

user1: lock the board

(venv) user1@ws1:~/work$ labgrid-client -p RO--MX6Q_sabresd--2 lock
acquired place RO--MX6Q_sabresd--2
(venv) user1@ws1:~/work$ labgrid-client who | grep RO--MX6Q_sabresd--2
user1  workstation1  RO--MX6Q_sabresd--2       2023-07-28 14:42:10.493009
(venv) user1@ws1:~/work$ labgrid-client  reservations
Reservation 'UYOHFZXX2A':
  owner: workstation1/user1
  token: UYOHFZXX2A
  state: acquired
  filters:
    main: name=RO--MX6Q_sabresd--2
  allocations:
    main: RO--MX6Q_sabresd--2
  created: 2023-07-28 14:41:28.345891
  timeout: 2023-07-28 14:43:10.493459

user2: release --kick the board

(venv) user2@ws2:~/test$ labgrid-client -p RO--MX6Q_sabresd--2 release --kick
warning: kicking user (workstation1/user1)
released place RO--MX6Q_sabresd--2

After step 3 , the board is not acquired by anyone , but it can be re-acquired/locked only by user1

(venv) user2@ws2:~/test$  labgrid-client -p RO--MX6Q_sabresd--2 acquire
labgrid-client: error: failed to acquire place RO--MX6Q_sabresd--2
(venv) user2@ws2:~/test$ labgrid-client -p RO--MX6Q_sabresd--2 lock
labgrid-client: error: failed to acquire place RO--MX6Q_sabresd--2
(venv) user1@ws1:~/work$ labgrid-client  reservations
Reservation 'UYOHFZXX2A':
  owner: workstation1/user1
  token: UYOHFZXX2A
  state: allocated
  filters:
    main: name=RO--MX6Q_sabresd--2
  allocations:
    main: RO--MX6Q_sabresd--2
  created: 2023-07-28 14:41:28.345891
  timeout: 2023-07-28 14:43:43.625886
(venv) user1@ws1:~/work$ labgrid-client who | grep RO--MX6Q_sabresd--2
(venv) user1@ws1:~/work$ labgrid-client -p RO--MX6Q_sabresd--2 lock
acquired place RO--MX6Q_sabresd--2

ElenaGrigore avatar Jul 28 '23 12:07 ElenaGrigore

Related to this: if a target is reserved, acquired, and then released without kick, it takes a good while before the reservation expires. Is this intended behavior? If not, it seems like release should be made to always clean up the reservation table, i.e. the fix for this bug can be to make sure that a released target also lets go of its reservation right away.

solbjorg avatar Jul 11 '24 09:07 solbjorg