[Automated-testing] master scheduler ideas

Remi Duraffort remi.duraffort at linaro.org
Mon Nov 18 00:40:55 PST 2019


Hello,

I took some time to think about the master scheduler.
This is only a draft and some material to start the discussion.

I can take some time to build a PoC.

Use case
=======

Allow to share devices between different users, where users can be either
individuals (developers, lab admins, ...) or CI systems (like LAVA or any
other tool).

The master-scheduler should be able to:
* book a device for a given user for a given amount of time
* "move" devices among users taking into account that some users might take
some time to release a device (like CI systems).
* when all reservations are finished, the device should be given back to
the original user (the "owner")

Words
=====

I believe that most actions would be possible with only two words:
"acquire" and "release".

These actions/tasks are stored in a database and would create a queue of
requests that the master-scheduler should handle.

acquire
-----------

Ask for the given board to be reserved.

This will add the requests into the device queue. When the device becomes
available, the master-scheduler will process the queue according to the
requests priorities and assigned it to the next user in the queue.

user: string
  the user that will acquire the device
duration: positive integer
  How long to keep the device
  should we set a maximum that only admins can exceed?
  Only admins can set this value to 0=infinite
priority: int in [0, 100]
  how important is this request
  only admins can use values above 75
reason: optional string
  the reason for this request
  can be used, for example, by admins when acquiring the device to unbreak
it

release
-----------

Release the device from the currently active reservation. Only admins or
the current user should be allowed to use this method.
If the current user is a CI system, the master-scheduler will let the job
currently running on the device some time to finish before releasing the
device.

The master-schedule will process the queue to know the next user for this
device.

reason: optional string
  the reason for this request
grace: optional integer
  grace period in seconds
force: boolean, False by default
  release immediately the device even if someone is using it. If the
current user is a CI system, the corresponding job will be canceled.

Examples
=======

CI-centric sytem
------------------------

The device D is always used by the CI and sometime (when admins are ok with
this), given to users.

The device is reserved for an infinite period (duration=0) for the CI
system by admins.
When a user want to use the device:
* user acquire D
* admin acquire (duration infinite)
* admin release D

The master scheduler will transfert the device to the user for a given
amount of time and then give it back to the CI.

Acquiring the device for the CI system is not mandatory as the
master-scheduler will give it back to the owner (the CI system in this
example). Unless more users acquire the device in the mean time.

User-centric sytem
----------------------------

The device D is often used by users and when not used, given to the CI:

The device default user is set to the CI system.

When a user want to use the device, the user just call acquire and the
master-scheduler will give the device to the user.
When the reservation is ending, the master-scheduler will just give it back
to the default user (the CI system).

Renewing a reservation
----------------------------------

In order to renew the current reservation, a user should just call
"acquire" again.
For a first PoC, this should be enough.

In the future, we can automatically tweak the priorities to make a renewal
first in the queue (unless admins placed an higher request).


What do you think?

Rgds

-- 
Rémi Duraffort
LAVA Architect
Linaro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/automated-testing/attachments/20191118/5b739718/attachment.html>


More information about the automated-testing mailing list