Status changes can now be marked as 'lazy', in which case they are only
applied when the worker has finished its current task. This only required
changes to the 'may-I-run' endpoint; it now ignores lazy requests.
The browser would pop out a `<worker-row>` element from a table because it
ejects all non-`<tr>` elements there. Apparently this doesn't happen when
the template is in a `<script type='text/x-template'>` tag, so we can
simplify.
Each worker now has a sleep schedule, which behaves in the following
way:
- When the schedule is not active, it doesn't influence the worker at
all.
- When the schedule is active, the worker is requested to be active by
default, unless the schedule allows it to sleep.
- When the schedule has 'days of week' set to a non-empty string, the
worker is only sent to sleep on those days. When 'days of week' is
empty, the worker is allowed to sleep on every day.
- The worker is allowed to sleep between the schedule's start and end
time. Those times default to respectively the start and end of the
day.
This fixes an incompatibility of the "latest image" server-side event
system with Firefox. Firefox really want to have an immediate event on the
SSE channel, or it'll think that the connection wasn't made properly.
Note that they aren't handled properly yet -- a check with upstream
Flamenco Server is still performed, which results in a 404 and thus an
immediate cancel.
When a status change is requested, /may-i-run/{task-id} and /task will
refuse the worker to run the task or get a new one. The newly requested
status is returned instead. This keeps happening until the worker
acknowledges the new status by a call to /ack-status-change/{ack-status}.
A sleeping worker can still get a task; there is no status checks on that.
The worker will just be marked as active then. It is up to the worker to
adhere to the status given by the Manager.
The worker can poll /status-change while sleeping to know when to wake up.
In a later version we possibly could turn this into a long poll.
This means a bit more adjustment on the part of developers that aren't
familiar with how Go does things, but it makes it more consistent and
easier to work with when on multiple Go projects.
Sybren A. Stüvel