labgrid-project / labgrid

Embedded systems control library for development, testing and installation
https://labgrid.readthedocs.io/
Other
327 stars 164 forks source link

release --kick doesn't clean the reservations table #1253

Open ElenaGrigore opened 1 year ago

ElenaGrigore commented 1 year ago

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
solbjorg commented 1 month ago

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.