Overhang.io

Question about Jupyter grader/viewer xblock support

Hi all,

I’ve been asked by a client to install the following xblocks in our tutor environment:

The viewer seems pretty straight forward to install with some minor modifications to our fork, but the installation steps for the ‘grader-xblock’ raises some concerns that I was hoping to get some clarification on if possible.

Regarding the grader xblock here are my general concerns:

  1. The description of the plugin states that it is generating docker containers for each student accessing notebooks, Does tutor support this? i know docker doesn’t tend to like nested containers, and the setup steps appear to require an install of docker-ce, so i’m not sure if there are additional steps needed to utilize this xblock within tutor, or if this is just allowing the plugin to execute in the parent docker environment.

the following two items may be better asked elsewhere, but in the event anyone knows off hand or has successfully installed the jupyter-edx-grader-xblock in tutor:

  1. During the installation there appears to be a migration utilizing ‘… cms migrate settings=aws’ is this signaling a dependency on amazon web services, if so this work order may be over before it started.

  2. Referencing the following issue on the tutor site from earlier this year which appears to have terminated without a conclusion after the creator was testing something (which is normally a good thing right? …optimism…):

  • https://github.com/overhangio/tutor/issues/84
    the xblock was at that time just releasing with edx - hawthorn support which appears to also be backwards compatible. but what about the future… Again, this is probably better asked elsewhere, but does anyone know off hand if this is supported by the ironwood release?

If it helps, My current environment is utilizing:
Ubuntu 18.04
Tutor 3.3.4

Any information is appreciated.
Thanks,
-CRivet

Hi @crivet! I’m terribly sorry about my lack of response, I was on holiday for most of the month.

I think you understand the issue that is at stake here: the xblock needs to be able to spawn containers. Since the xblock runs inside the LMS runtime, the docker containers need to be launched from inside docker. This is quite possible, and thus (theoretically) supported by Tutor, but it does require a little bit of work.

If you ask me, I’m not a big fan of the design decisions that went into this xblock. IMHO it would make better sense that the xblocks communicates with a server that would itself be responsible for remotely launching the containers. Many people are interested in having a fully functional Jupyter XBlock, so maybe someone could do a complete rewrite? :angel:

The “aws” settings were the settings used by edx.org for deploying to production prior to Ironwood. They were later renamed to “production”. They still point to many AWS services, such as S3, but Tutor takes care of overriding the right settings so you don’t have to rely on AWS. You should be able to safely replace “aws” by “tutor.production” in all deployment instructions.

Indeed, you should probably ask this one directly on the xblock repo :slight_smile: https://github.com/ibleducation/jupyter-edx-grader-xblock/issues

Thanks for the information @regis , and don’t worry about the delayed response. Everyone needs a vacation.

for record keeping i’ll share my experience:

I was able to get the ‘viewer’ plugin though it did require additional changes to the edx-repository to add additional urls, and allow at a minimum ‘same-origin’ request policies to allow the rendering of the jupyter notebook. (not ideal but functional)

For the ‘grader’ variant, I ended up shying away from installing this and went with an alternative ‘colab_xblock’ which links to Google’s new Collab app, as this one just links to Jypyter notebooks hosted in a google drive environment instead of generating an abundance of containers.