(this is a docker container id, not a foreign key)

(open_bar access will typically be used for global runners, not
belonging to a particular user)

BERJON Matthieu authored Jun 19, 2018 and BAIRE Anthony committed Jun 20, 2018

Now a super user has the possibility to create an "open-bar" runner. A
flag is entered in the database to specify its type. When specify like
this, any application can be run on it.

The model has been updated to add the `open_bar` boolean field. The `account`
foreign key has been renamed to `user` to be coherent with the other models.
I updated the `RunnerForm`.

The template received a big update to separate the applications to select from
the open bar boolean. The open-bar element is seen only if the user is a super user.

An error was raise when creating a job related to `Exception Value: type
object 'WebappVersion' has no attribute 'COMMITTED'`. The issue was the
misspelling in the model (missing a 't' at "committed"). This commit fix
this issue.

Resolves: #180

Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

mentionned by !41

`docker_name` is *not* the same as `name.lower()`

I added the possible choices for the `result` field and setup its
default value to `NONE`.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added the different choices available for the state of JobQueue.
And set up the default value to 0 (new job).
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

When using the admin panel, the creation of a new user weren't allowed
without giving a SSH key. As it's not a mandatory data I added in the
model the possibility of living it blank or equal to null.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added in most models a `__str__` method that is used for debugging and
used as well in the admin panel to display data.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I changed the url field into a `URLField` instead of a `TextField`.
I defined as well a specific method that is used for debugging and in is
used in the admin. I commented it because it creates a bug into the
admin panel since the changes introduced in the model for the webapp
creation (the adding of the foreign key in the Webapp model).
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

The webapp creation is done in two steps. A first step that writes the
information in the database. Once the controller has created the
sandbox, the user is allowed to push its application on it and create a
new version.

I updated the models in order to satisfy the current state of the rails
database. I transformed the `sandbox_version_id` as a foreign key as
it's supposed to be in the rails `Webapp` model.
I updated the `WebappVersion` model to add the `state` possible choices.

I updated the webapp sandbox form in order to take into account the
`WebappVersion` model and add the related necessary fields.

I updated the `UserWebappListView` view to match the updated model. I
used as well a context object name to get a handle in the template with
a meaningful name.

The `WebappCreateView` now create an object in the database with all the
necessary data.

The `WebappSandboxCreationView` view create the sandbox and update the
Webapp model with the new version that has been committed.

I updated the templates in order to perform several specific actions.
I added a block called `meta` in the base template. The underlying idea
is to be able to supercharge on page basis the meta tags in the head of
the page. It used in the `webapp_creation_form.html` file where the
refresh every 5 seconds the page to read the database in order to know
when the sandbox is in its "running" state. Afterwards the meta tag is
removed to access the sandbox creation form in order to commit a new
version.

Resolves: #170

Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the model by adding a `__str__` method and update the admin
display data inside it. I added a first batch of tests for this model.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added a proper docstring to the `generate_token` function.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

The `rest_framework`package in the model wasn't use anymore, therefore I
removed it from the file.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the model for the webapp creation. Now the sandbox version is
activated (though not used yet in the application). I updaed as well
the sandbox possible states
I did some naming modifications to be more coherent throughout the model
(removal of the `dj_` prefixes on foreign keys).
I adapted as well the script migration to take into account these
changes and save in the tree the django migration file.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

In order to create the webapp creation route, I added to perform several
changes in the model, view, form and template.
I updated the `sandbox_state` with a default value to 2 (starting). It
correponds to the state when a webapp is created and the container needs
to be created by the controller.
I added specific choices corresponding to the possible states the
sandbox can be in. it avoids to enter any values that wouldn't be
interpreted by the controler.

I added a route for the webapp creation that can be accessed by
registered users (any registered users at the moment).

I created a new view relation to webapp creation. This view corresponds
to the creation of a new webapp object according to a form and the
creation of a quota object afterwards with default settings.
I added a link to redirect to the webapp creation form.
I added a template to display the form for the webapp creation route.
I added a form for the webapp creation.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I set up a default value for the quota to 1MB.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

In order to be coherent with foreign key naming, I updated the two
foreign keys in the `Quota` model. The migration SQL script has been
updated accordingly.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

In order to circumvent the issue of the generation of a unique token at
the object creation in the database, I changed the default value by a
callable object. This corresponds to the creation of a very simple
function called in the `default` argument of the related field.

Resolved: #151

Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

In order to add a link to a Jupyter notebook I had to perform several
changes.

The URL field provided by django is unable to manage git url type such
as `git@example.net:user/repo` therefore I changed to a CharField.

I updated the field validator for the field `notebook_gitrepo` and use a
generic regex. At the moment I ensure that the url corresponds to
`git@something`. It's a bit light but it's a start.

I added the jupyter hub link for an authentified user that is the owner
of the application in public webapp list.

I fixed as well a missing closing tag.

The placeholder attribute in the webapp update form on the
`notebook_gitrepo` form was wrong. I fixed it and updated the content in
order to specify the type of url expected.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

A user can manage one app (several later). In order to be to do that I
created two views. One to list the apps belonging to him, another one to
edit a given app. Two routes have been created as well to perform these
actions. Two forms and templates have created as well and modified to
correspond to the current graphical chart. The user menu and the public
webapp listing have been updated to show the buttons to list or edit the
apps wherever it applies.

The model of `Webapp has been modified as well. A first modification was
about the `private` that was an integer. Because the value can be only
true or false, I changed it to a boolean. A field has been added called
`notebook_gitrepo` that corresponds to a URL to a git repo and used to
call the Jupyter hub and run the notebook.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

In order to follow Sébastien's advice, the `AllgoUser` model take a
default value on the token rather than overriding the save method in
order to prevent any issues if a user is generated by bypassing the
django user model.

I changed the view in order to generate a new token each time the user
wants to do so using a HTML form. This change follows the token
generation modification in the model.

Because we don't use the rest_framework anymore, I removed the call
inside that form.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

It fixes an error in the docker_os model that was inherited from
TimeStamp model but doesn't have the rows `created_at` and `updated_at`.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I updated the model name of the views.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

The current process to migrate the data suffers from side effects,
especially when the database needs to drop, start from scratch and add
some migrations through Django. Django handles really badly an existing
database and it's impossible to reproduce a migration process from
scratch when django migrations had been add up to the current database
migration process.

This commit resolve this by reversing the process from migrating to old
database to the new one and telling django to take this new database as
it is to telling Django to create the database from his models and
then inserting the data into the new database. By doing so, any
migration applied through Django is taken into account at any stage
during the process.

During the rewriting of the migration process I discovered several
issues that needed to be addressed.

- deletion of the token management library
- add of a token field in the allgo user table
- add of foreignkeys instead of onetoone fiels in the webapp to avoid a
uniqueness issue on fields that were supposed to have several times the
same ID.
- Update of the default values of job's fields
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

The current process to migrate the data suffers from side effects,
especially when the database needs to drop, start from scratch and add
some migrations through Django. Django handles really badly an existing
database and it's impossible to reproduce a migration process from
scratch when django migrations had been add up to the current database
migration process.

This commit resolve this by reversing the process from migrating to old
database to the new one and telling django to take this new database as
it is to telling Django to create the database from his models and
then inserting the data into the new database. By doing so, any
migration applied through Django is taken into account at any stage
during the process.

During the rewriting of the migration process I discovered several
issues that needed to be addressed.

- deletion of the token management library
- add of a token field in the allgo user table
- add of foreignkeys instead of onetoone fiels in the webapp to avoid a
uniqueness issue on fields that were supposed to have several times the
same ID.
- Update of the default values of job's fields
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added the creation of a token at the user creation.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

It fixes an error in the docker_os model that was inherited from
TimeStamp model but doesn't have the rows `created_at` and `updated_at`.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

I added the logo and updated the README page to give insights on the
font dependencies.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>

Add of jobs API

I added a partial but fonctionning REST API for the jobs management.
It's possible to list jobs according to its username, you can create,
  update and delete a specified job related to its username.

In order to do that I used a new django package called rest_framework.

I had to do minor modifications in the model because of some bugs but it
doesn't have any impact on the current state of the database.

I created a subapp called `v1`for the API to keep track of the versions
and avoid users to have strange behaviours and have time to switch to
the new API version before a full deprecation.
Signed-off-by: Matthieu Berjon <matthieu.berjon@inria.fr>