openfun / fonzie Goto Github PK

Purpose

We need to add documentation on how to install & configure Fonzie in a fun-platform's docker stack.

Proposal

Once a we will have a running POC, we need to describe our procedure.

Purpose

We need to document the way our contributors can start playing with Fonzie on their machine.

Proposal

This section of the documentation can be written as a contributor/developer guide.

It may be related to #4.

Description

We should use same code quality standards on every projects.

Solution

Use Richie's one on this project and fix new quality warnings

Description

#15 added a new endpoint and it needs Dredd tests.
Being subject to multiple access control verifications this endpoint tests need specific fixtures to work (see unit tests).

Description

When solving issue openfun/openedx-docker#106 (Controlling access to instructor dashboard CSV export files) we had to determine if user requesting the file was belonging to course staff.

Solution implemented by #15 may not safely scale if user belongs to a large amount of courses because we request ORM for an unknown number of lines and then calculate each course key sha1

Considered solutions

• Retrieve course_key from HTTP referer
• Implement specific DjangoStorage
• Override view listing available files (list_report_downloads) to append course_key to filenames
• Monkey patch edX ReportStore class

None of these solutions were considered satisfying.

Description

When instructor dashboard is used to generate CSV file for course problem responses, it create a file named with course and problem keys of the form:

INSTN_0000_session01_student_state_from_block-v1_instance+coursenumber+sessionnimber+type@poll+block@dc26dcd145d04ed18e13084e91e3748c_2019-10-07-1528.csv

this url pattern cant match it resulting in 404 error
when instructor attempt to download it
https://github.com/openfun/fonzie/blob/master/fonzie/urls/acl.py#L15

Bug Report

Problematic behavior

When a new user who doesn't validate his email want to log in, he is redirect to the source page. He cannot reach the login page.

The API endpoint /api/v1.0/user/me return the code 403.

Expected behavior/code

Have the login page with a message who request to validate the email.

Steps to Reproduce

1. Create an account on fun-mooc.
2. Do not validate your email
3. Click on the log in button

Purpose

Our development environment relies on Docker and docker-compose, leading to permission issues on HOST while working on the project. To solve these kind of issues and ease developer on-boarding on the project, we wrote a bunch of shell scripts (bash) to build, run and test Fonzie.

Even if those scripts are relevant to improve the developer experience, they raise two kind of problems we need to address:

1. wrapping docker(-compose) commands can appear unnecessary for advanced users that prefer using docker raw commands,
2. hiding the underlying docker complexity will not incentive new users to learn it from the basis.

Proposal

We need to exhaustively document those scripts to explain what they are doing (by comparing them with docker(-compose) raw commands) and how they can ease the developer life.

Purpose

It is commonly assumed to be a good practice to avoid using the root user or any other privileged user to run an application in Docker containers. Moreover, when working on a dockerized project like Fonzie, we need to mount host volumes containing at least the sources of our application and temporary assets. In this condition, building the container (using a privileged user) can create files with high level permissions on the host system.

To prevent this last situation, we have wrapped docker build and run commands to use the local user/group ID in our containers. The counterpart of this is that our containers are system-specific and won't work anywhere else. For now, there is no big deal with this as long as our container will not get distributed or used anywhere else than on each developer's machine.

But this can appear as a complex implementation as things can get simpler following OpenShift guidelines.

Proposal

In our Dockerfile, give the container's user permission to write in the /etc/passwd file, create a user (that will run our container) with a random user ID, and define an entrypoint that will create a new user mapping the host user with the container user:

RUN chmod g=u /etc/passwd
ENTRYPOINT [ "uid_entrypoint" ]
USER 1001

The entrypoint creating this user looks like:

if ! whoami &> /dev/null; then
  if [ -w /etc/passwd ]; then
    echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
  fi
fi

Neat. Classy. 😎

Purpose

Writing documentation using Restructured Text format feels really painful nowadays. Now that PyPI natively supports rendering project descriptions formatted with markdown [1] and read the docs also supports markdown formatted documentation (using MkDocs), I think it's time to switch to markdown FTW!

[1] https://dustingram.com/articles/2018/03/16/markdown-descriptions-on-pypi

Proposal

• convert *.rst documentation files to *.md
• remove Sphinx and it's dependencies (edx theme, etc.)
• add mkdocs dependency and configure it
• update documentation build & clean methods (Makefile)

Purpose

We extensively use CircleCI these days. To avoid having to handle multiple CI platforms and scripts, let's switch to CircleCI for Fonzie too 🎉

Proposal

• Remove .travis.yml
• Rename bin/ci steps to something more generic (at least not travis-driven)
• Add .circleci/config.yml
  • build the fonzie container to use for testing
  • run tests in this container
  • run spec tests with a running stack
  • re-implement PyPI package upload

Purpose

We need to setup a POC for Fonzie packaging and publishing to PyPI.

Proposal

• Follow recent packaging good practices to improve current setup.py
• Setup new relaese publication to PyPI with TravisCI