GitLab

I added the legacy database model into the app.

In order to do that I:

- created the urls.py and views.py file (required by Django)
- created the legacy model using the inspectdb tools given by Django and
stored in models.py
- followed the process to initialize the migrations at the stage of the
model (resulting in the creation of the migrations folder)
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I created the poc app that will ensure the complete use of the legacy
database. At the moment this app doesn't work properly (no url, views or
model defined).
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added a README file in order to document the process of mapping a
current legacy database with Django. It's required only at the start of
the project or creation of a new app calling a legacy database. This
helps to start the historic of the migrations to the current state of
the database.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

Update the of README file

I updated the documentation to precise the fact that the migration
process must be applied for each app calling the legacy database.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added the poc app. It adds the app to the settings of the project and
load the url patterns from the app.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I created the Supervisor configuration file. At the moment, the
configuration hasn't been tested because of the incompatibilities of
Supervisor with Python 3. It still needs to be resolved.

The configuration has been copied from Rails and adapted to run a Django
application and later on a Redis cache system (commented at the moment).
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

In order to launch the app, I create this script. It just launch the
Django internal HTTP server on the port 4000 (later on, it should
handled by Gunicorn or any WSGI server).
Then I launch the nginx server.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

In order to mimic the Rails container using Django, I installed a Nginx
reverse proxy that communicate directly with the Django application
(through Gunicorn or directly).

The current configuration is a copy of the Rails configuration except
the listening port.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the Nginx configuration that is generated in the Python
script. At the moment the configuration is hard-coded and need to be
improved. It's working as such at the moment.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I update the initialisation process (that was empty before).
I create the different folders to host the logs, cache and others.

I create a symbolic link for the following:

- a run-allgo script that instanciate the Django app and Nginx
- supervisor configuration (at the moment, commented)
- nginx configuration

I then execute the run-algo script. At the moment, it seems that the
execution of this script either doesn't occur or create an error with
docker compose at launch (the dev-django container doesn't run). So at
the moment, I run by hand the script once the container is up.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the packages installed in order to:

- remove some unecessary packages related mainly to Rails
- add packages relation to python 3 and Django

I updated the container initialisation that seems to fit the current
practice with other container initialisation process.

One thing to mention. Supervisor can't work with Python 3. Anthony
suggested to install Python 2 just to make Supervisor happy and run
Gunicorn/Python 3 as such.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I deleted some commands that were commented because they were specific
to rails and not relevant in the Django context.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

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