Raising the errors would crash the current thread. As this thread
contains the Eventmachine, that would influence other connections
as well. Attaching the errors to the connection and reading them
after the connection was closed ensures that the thread stays
alive while handling the errors in the main thread of the current
request.
In order to provide an alternative to Poseidon, a strategy for the
DockerContainerPool is added that is used by the runner model.
Co-authored-by: Sebastian Serth <Sebastian.Serth@hpi.de>
Timeouts are now handled correctly and the Runner automatically
creates the execution environment if it could not be found in
Poseidon. The runner is deleted locally if Poseidon returns
a bad request error.
The runner model is only a class responsible for storing information
now. Based on the configuration it picks a strategy for the runner
management. The Poseidon strategy is already implemented and tested.
The Docker strategy will follow.
The errors are raised in the runner model and in the runner connection
class. In the submission controller the errors are rescued and,
depending on the error, the status timeout / container depleted is
sent to the client.
When creating or updating an execution environment, an API call to
Poseidon is made with the necessary information to create the
corresponding Nomad job.
If runner management is configured, his will display a warning
(currently in the same color as if it were a success) in the UI, if the
API call fails. The environment is saved even if it fails.
If runner management is not configured, this warning will not be created.
The old approach was to require the runner connection. This did
not work anymore with Zeitwerk in Rails 6. @sebastian.serth and I
moved the Connection class in `lib` into the ActiveRecord class
`Runner`. This will also work with future changes like specific
error classes. Furthermore the config was fixed and simplified.
Co-authored-by: Sebastian Serth <Sebastian.Serth@hpi.de>
