[Automated-testing] board reservations (was RE: Farming together - areas of collobration)

[Bird, Timothy]

I wish these thoughts were not all comingled into a single thread,
so that different topics could have their own threads.  I find responding
to lots of issues simultaneously in a single large message cumbersome.

In that spirit, I'm going to break my responses into different messages.

> -----Original Message-----
> From: Jan Lübbe on Wednesday, November 15, 2017 1:37 AM
> On Tue, 2017-11-14 at 21:37 +0000, Bird, Timothy wrote:
> > > -----Original Message-----
> > > From: Kieran Bingham on Saturday, November 11, 2017 7:37 AM
> [...]
> > > That is to say - for me - I envisage that a developer should be able to 'lock'
> a
> > > board, take control of it, and use it and then release it. (Or a timeout
> would
> > > release the lock as well perhaps)
> >
> > I agree with this concept.  'ttc' has board reservation.  (I'm not saying this
> > promote 'ttc', but rather to indicate that it was one of the things we added
> > based on our usage models for board farms at Sony.)  I'm not sure
> > where board reservation fits in the layer model - probably at the "cow"
> > layer.  (BTW - the layers will need non-analogy names at some point.)
> 
> > > An automated test system - should then simply be another 'developer'
> who just
> > > happens to be an automated build and test system. Whether a real
> person, or a
> > > build pc - the access should be much the same. (albeit perhaps with their
> own
> > > unique access keys and permissions of course)
> >
> > I think this makes the model of managing the board for multiple use cases
> > simpler.  If there are differences between human/board interaction
> > and automated-system/board interaction, it would be good to identify
> > those.
> 
> I think the main difference between interactive (during development)
> and CI use is that the CI can wait until the board is free again.

Good observation.  Maybe a priority system, allowing one actor
to break the reservation, or request to break the reservation,
would be good.  Sometimes a human needs to get something done,
and should be able to interrupt a CI job.  But also, maybe a human
is not doing something important, or left a reservation on by mistake,
and the CI should be able to interrupt the human (or at least
request to grab the board).

> 
> The "Cow" layer shouldn't handle scheduling like Jenkins or Lava do it
> (because that would cause problems when using those as the top layer).

When you say scheduling like Jenkins or Lava - are you talking about
scheduling of the board for test jobs?  I would agree with this.  That's
two different levels.

> We can probably get away with just reservation/locking on the Cow
> layer:
Agreed.
> For Jenkins you could have a pipeline job first run the build, then
> reserve a board and wait in a lightweight executor until it's available
and possibly notify the actor holding the board that a job is waiting
for the board.

> and then continue with running the tests. That way, the test results
> would be attached directly to the build (and this way to the original
> SCM changes).

 -- Tim