Currently, the biggest issue with TestingFarmProvisioner is that it doesn't track expiring reservations to re-provision a system when it's about to expire - the current API makes that kind of hard as we'd need to calculate test runtime (only really available with fmf metadata, not always with others) and estimate whether that would be enough for the leftover reservation time.
Instead of doing that, there's potentially a better solution on the horizon - a dedicated Reservation API to be implemented by Testing Farm.
That API would theoretically allow us to extend the reservation time (pipeline timeout) on-the-fly, avoiding the issue entirely.
In fact - it would ideally allow us to do 5-minute extensions every ie. 2 minutes, and if the ATEX-using Python program freezes or is forcibly killed, the reservations expire within 5 minutes, instead of being left for the entire long reserve duration.
Currently, the biggest issue with TestingFarmProvisioner is that it doesn't track expiring reservations to re-provision a system when it's about to expire - the current API makes that kind of hard as we'd need to calculate test runtime (only really available with fmf metadata, not always with others) and estimate whether that would be enough for the leftover reservation time.
Instead of doing that, there's potentially a better solution on the horizon - a dedicated Reservation API to be implemented by Testing Farm.
That API would theoretically allow us to extend the reservation time (pipeline timeout) on-the-fly, avoiding the issue entirely.
In fact - it would ideally allow us to do 5-minute extensions every ie. 2 minutes, and if the ATEX-using Python program freezes or is forcibly killed, the reservations expire within 5 minutes, instead of being left for the entire long reserve duration.