In the current tutor yml config templates there is support for separate lms-env and cms-env patches but no common-env patch that would be shared between both services. As a result, our tutor plugin that defines settings which need to be set in both lms and cms require redundantly setting the values within both the lms-env and cms-env patches.
First, I would like to ask if there is an existing pattern that I am overlooking which would make it easy to define the values once and have them applied in both lms.env.yml ad cms.env.yml?
If not, is there a reason that common-env should not be added in both templates as well?
I would be happy to create a pr to contribute the change, if it would be welcome, but I wanted to confirm first before I spent the time.
[food-for-thought] At edX/2U we’ve moved away from shared configs because of separate problems that type of hierarchy introduces. Note that there are configurations that are shared across all services, like auth configs as an example. Does it hurt us to special case common configs between LMS and Studio, rather than treating them like two separate services that happen to need some matching configs? Coudl we simply add appropriate comments for sections of the config that need to match in other services?
I’m not an expert in this area, so simply sharing some thoughts.
The longer explanation is that I hate the lms/cms.env.yml files. I’d rather use them as little as possible. Actually, I should add a comment at the top of this file. I’d rather encourage plugin developers to add their common settings to the “openedx-common-settings” patch, in Python.
Yes, I would agree with this approach. If a setting is used in two different places, then it should be defined in just one place.
There is a much longer conversation to be had on Open edX settings. After all these years, it’s still one of the hardest things about edx-platform – though there has been a lot of improvement over the past couple releases, in particular thanks to much-improved docs.
Thank you @regis. I had actually considered moving all of my settings into the python openedx-common-settings patch, but there was one part I wasn’t confident about. If the settings values are defined in the *.env.yml config files, then from the startup of the container those values are defined instead of the default config settings. If they are moved into python, then the *.env.yml files will be generated (by tutor config save) containing default tutor defined values and only later get overwritten when the python code is run. I’m unaware if that might expose me to unexpected side-effects, so I assumed it would be safer to define the intended values at the source rather than at a later step. Do you think this is a consideration I need to respect when choosing how to proceed?
Thanks for the suggestion of openedx-auth since it hadn’t even occurred to me to use that patch for any purpose other than its name implied. I guess this is a reasonable alternative if it makes sense to stick with yml instead of moving toward the python direction.
Although I don’t disagree with the logic of what you said (de-duping), I simply want to clarify that you said the opposite of what I said. The crazy hierarchy of playbooks in edx-configuration got people scared, so we’ve gone to the other end of the spectrum, and everything is now duplicated.
I’m talking about 2U/edX, not Tutor, in case this would have caused confusion.
It really depends which setting you are trying to override. Some need to have their values in the yaml files. You need to check how the values are processed in the edx-platform repo common/production settings.
Right I’m not sure where the truth lies, but I’m pretty confident that 100% duplication is not the right way to go for the rest of the community… though it’s great if it works for 2U.
I’m not sure where the truth lies, but I’m pretty confident that 100% duplication is not the right way to go for the rest of the community… though it’s great if it works for 2U.