Reservation durations

[hornbackzacha]

My organization is transitioning from an environment where developers and testers have units at their desks to a labgrid-enabled library of units. I'm loving labgrid, thank you for your hard work.

One issue we've experienced, since we're replacing desktop development usecases, we see developers reserving units for long periods of time. Other users waiting in queue have no idea how long they can expect to wait.

Another issue, especially with new users, people forget to release the unit after they are done. We made scripts to automate this, but in part we just moved the problem. Bugs in the script can now fail to release the unit.

The combination of these two issues made them worse. Our initial set of labgrid users were running relatively quick test suites and then releasing the unit. So when someone was on the unit for "long" periods of time users simply reached out to their peers and handled the situation. The addition of users with longer usecases has stalled this communication. After a few times asking peers who were using the system for valid reasons, other users stop asking. Then when someone mistakenly holds a system after they're done, it takes longer to identify.

In other areas of life, when I have a reservation I am often asked to provide an estimate for how long I'll hold the item. For example, hotel rooms are not reserved indefinitely, you specify the number of nights you expect to stay. This gives the hotel and other customers the ability to plan future usage.

Finally getting to my point, I'm proposing the addition of a reservation duration to labgrid-client reserve. This duration could default to 0, meaning indefinite/infinite duration, allowing current happy users to stay that way. The reservation duration would be reported via the output of labgrid-client reservations, giving other users an idea how long they might wait in queue.

I believe the consequences, if any, of overstaying your reservation should remain a decision for each organization. I could imagine some instances where forcefully kicking a user from the unit when the reservation expires would make sense. I could imagine some instances where the reservation owner should stay on the unit. Each organization can make that decision for themselves and enact appropriate processes via scripting accordingly.

For extra credit, we could also add labgrid-client extend-reservation. In the cases where a user is about to overstay their estimated duration, it would be helpful to allow for extending the estimated reservation duration. At least this would update stale information for any users waiting in queue. In instances where an organization decides to kick users that overstay their reservations, this would allow the user to stay on the unit.

So far (hopefully not too obviously so) I've said a lot of this in ignorance. I haven't familiarized myself with the inner workings of Labgrid. I would like some level of buy-in from the community. If there is interest enough to proceed, I'm happy to educate myself and put together a PR.

I'm also open to alternative solutions to resolve our issues and/or modifications to the above proposal.

Thanks for the time.