GitLab

I created a minimal Django app that by default generate a SQLite
database at the root of the project and display a basic page saying "it
works!" on the port 8000.

I added as well a requirements.txt file that install the LTS version of
Django (v1.11).
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added a .gitignore file dedicated to Python.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added a container_init file as it's required by the stack. It will be
used later on anyway to setup the Django app.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

Thanks to Sébastien, I updated the Dockerfile in order to resolve issue
realted to unknown container_init. In the end, I copy this file into the
init file and give the right permission to it.

I removed as welle the symbolic link to Python3 as it seems to be the
standard on this Debian image.

I removed the command "run-allgo" as it was coming from the rails
Dockerfile which is not relevant at this stage of the image.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I modified the main file to build the new django image called
dev-django. I added the folder in the bootstrap and prepare.sh file.
I added the necessary configuration in the docker-compose.yaml based on
the rails example.

At the moment, the container by itself doesn't do anything except having
the python stack installed.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added the Dockerfile for the future Django application. It's based on
the rails Dockerfile with the following tweaks:

- Installation of Python 3 and pip
- Edit of the Python symbolic link to force the use of Python 3 by
default

I decided to store the app in the same folder as the rails app was as
they are not meant to work side by side. It will also facilitate the
debugging for developpers who were working on the rails app. If they
need to look into it for debbugging reasons, the path where to find it
is still the same.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

(was rejecting base64 padding bytes "=")

but disable the widget for non-admins

this variant is closer to the actual meaning
(the fact that the limit was reached does not automatically imply
 that the process is starving, we cannot decide how much memory
 a process needs without doing some profiling)

(will be less confusing, also "done" is more neutral than "success"
 it applies well to past jobs that have errors)

fix #96

fix #55

fix #121

fix #125

- to have SIGTERM forwarded to the process
- to propagate the exit code of the process

(should be less confusing)

to let the task implementations detect that they are being rescheduled

- add a pending task
- add a timeout

(disable_future_warning)

console log level:
 (default)    ->  WARNING
 -v/--verbose ->  INFO
 -d/--debug   ->  DEBUG

log files:
  /vol/log/controller.log   -> INFO
  /vol/log/debug.log        -> DEBUG  (disabled unless -d/--debug or
                               unless env var DEBUG is set)

- add SwarmAbstractionClient: a class that extends docker.Client and
  hides the API differences between the docker remote API and the
  swarm API. Thus a single docker engine can be used like a swarm

- add SharedSwarmClient: a class that extends SwarmAbstractionClient
  and monitors the swarm health and its resource (cpu/mem) and manages
  the resource allocation.
  - resources are partitioned in groups (to allow reserving resources
    for higher priority jobs)
  - two SharedSwarmClient can work together over TCP in a master/slave
    configuration (to allow the production and qualification platforms
    to use the same swarm without any interference)

- the controller is modified to:
  - use SharedSwarmClient to:
    - wait for the end of a job (in place of DockerWatcher)
    - manage resource reservation (LONG_APPS vs. BIGMEM_APPS vs normal
      apps) and monitor swarm health (fix #124)
    - NOTE: resources of the swarm and sandbox are now managed
...

(because rails requires these files/directories all the time)