Fix workers state changing behaviour 02/188902/13
authorLukasz Wojciechowski <l.wojciechow@partner.samsung.com>
Tue, 11 Sep 2018 12:53:05 +0000 (14:53 +0200)
committerLukasz Wojciechowski <l.wojciechow@partner.samsung.com>
Thu, 4 Oct 2018 13:29:57 +0000 (15:29 +0200)
commit70f4a1bb1750c17c5b3691c22a621291b32fa067
tree6088dd6d0d9efbfbb1ce649f9627bc2afe8a634c
parent893451b1cb040e7a4a22f3fe03a179ab832f58bf
Fix workers state changing behaviour

Changing state to IDLE (with key generation) or to MAINTENANCE is
a time consuming operation. That's why new workers' states are
introduced:
* PREPARE - when entering IDLE;
* BUSY - when entering MAINTENANCE.

Without them, state of workers can be changed during these long
operations as another method call can change the worker state
or initiate another long operations breaking actual state of workers.

To fix this issue not only new states are introduced, but also
an additional goroutine for every registered worker is started.
The goroutine is responsible for running long operations
in background. It is controlled with a channel through which
new worker state is sent every time setState is called.
The goroutine breaks execution of current long operation if new
state is set for worker.

As new states appear some changes in workers' methods behaviour
needs to be changed:
* SetFail returns ErrInMaintenance also for BUSY state
    (formerly for MAINTENANCE only).
* SetState ignores attempts to set MAINTENANCE when worker is BUSY
    and to set IDLE when worker is in PREPARE because requested
    state changes are already in progress.
* PrepareWorker is allowed to be run only for workers in RUN state.
    This method is used in two cases: when Job is finished
    or when matching of reserved worker and request fails to create
    the Job. In both cases worker should be bring to IDLE state
    only if if it was in RUN state. If it was in MAINTENANCE
    or FAILED it should be kept that way.
* OnWorkerFail is sent when worker's Job was interrupted (if it was
    in RUN state, and enters any other than IDLE or PREPARE states).

Naming of methods parameters has been unified. All methods running
for a boruta.WorkerUUID use uuid variable and a worker variable
is used for mapWorker structure.

Change-Id: I8d1d8b55e48e432746ebf819650a77698b8c27ab
Signed-off-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
boruta.go
workers/error.go
workers/worker_list_test.go
workers/workers.go