I’d like to start a discussion to break down the functionality of config.yml, what it can, and what it can’t be configured to do. My understanding so far is that it ports the settings to the lms.env.json config file and reloads these on
tutor config save and initiate them on
tutor local quickstart.
But does it also redirect settings to cms.env.json? And what about cms.auth.json and lms.auth.json?
Are all the FEATURES: parameters supported, and do I need the heading FEATURES in config.yml, or will it know?
I’m trying to build an understanding so that I can plan a way to preserve my settings regarding:
ENABLE_LTI_PROVIDER, ENABLE_THIRD_PARTY_AUTH, THIRD_PARTY_AUTH_BACKENDS,
and in the lms.auth.json:
Hoping for more insight!
Hi @ak00001! Indeed, there is some misunderstanding here. Let’s break down how
tutor config save --interactive works:
- You are being asked a couple basic questions about your platform: this sets a few tutor configuration parameters (
- The configuration parameters collected in step 1 are aggregated with the default settings from this file and from the various plugin settings: https://github.com/overhangio/tutor/blob/master/tutor/templates/config.yml
- The settings that differ from the default are stored in
$(tutor config printroot)/config.yml. It is important to understand that, at this stage, the settings stored in this file do not directly configure your Open edX platform. Instead…
- … the configuration parameters from
config.yml are used to render many configuration templates, stored in the following template folder: https://github.com/overhangio/tutor/tree/master/tutor/templates These templates include, among others, the
lms.auth.json (see common template), the lms and cms production django settings, the nginx and mysql configuration files, the Dockerfile for all containers, etc.
- The rendered configuration files from step 4 are stored in
$(tutor config printroot)/env. Collectively, these files represent the platform “environment”.
Then, when you (re)start an Open edX platform, the files from the platform environment are used to configure the various services.
Thus, you should understand that adding arbitrary values to
config.yml will not affect how your platform work. Instead, you should patch the configuration templates. To do so, you could (but shouldn’t) fork tutor and directly modify the templates. This is not the recommended approach, as it makes it difficult for you to easily upgrade Tutor. Instead, you should create a tutor plugin, as explained here: https://docs.tutor.overhang.io/plugins.html#api-v0
You will install and enable your own plugin that will patch the right files, in the right places with the right values. Some major players are running tutor this way, without having to fork tutor.
Thanks for the clarification Regis! We’ll get to work on an LTI + THIRD_PARTY_AUTH plugin
And if any of the major players should be willing to open source/share their work or give insight into their deployments with custom plugins we’re happy to learn
Here you go: keithagroves/tutor-enableLTI
I don’t really know what I am doing, but I gave it a shot working off of another plugin. @regis am I doing this right? If anyone wants to let me know what else needs to be done to Enable LTI with my plugin, it would be appreciated.
This is looking good @keithagroves! Is it working?
I see that you are versioning the tutor_enableLTI.egg-info folder; this is unnecessary and this folder should be added to the .gitignore file. Next time, I suggest you try out the tutor plugin cookiecutter: https://github.com/overhangio/cookiecutter-tutor-plugin/.