I would like to set OOD_DATAROOT for some interactive apps. For other apps, like the job composer, I was able to follow documentation here and add an env file to /etc/ood/config/apps/myjobs/env . However, the same configuration does not seem to work for rstudio and interactive desktops. For example, putting an env file in /etc/ood/config/apps/bc_desktop does not seem to have any effect.
I have also tried putting the env variable in /etc/ood/config/nginx_stage.yml by using the “pun_custom_env” key as described here. However, I need to use $USER when setting OOD_DATAROOT. Something like OOD_DATAROOT=/home/$USER/.ood_portal works fine in an env file, but when set in nginx_stage.yml like OOD_DATAROOT: "/home/$USER/.ood_portal", "$USER" gets read as a string literal.
The interactive apps are all managed by the Dashboard Passenger app, and the dataroot for that app can be configured using /etc/ood/config/apps/dashboard/env like you do with the Job Composer. By changing that, you will change the root where all of the interactive apps go.
I have a somewhat related question, but about myjobs. One of our clusters does not have read-write /home directory, so I was trying to make the submission of the job templates to be from /work instead. I have followed the link @tbpetersen shared, and tried with both /var/www/ood/apps/sys/myjobs and /var/www/ood/apps/sys/myjobs/initializers/ood.rb, but the jobs are still being submitted from /home. Setting OOD_DATAROOT works well for both Interactive Desktop and Apps. Am I missing something additional in the setup?
Quick update - after few attempts, changing /var/www/ood/apps/sys/myjobs/env to /var/www/ood/apps/sys/myjobs/.env" set the correct directory, and the template job is now being submitted from the path set with OOD_DATAROOT. What would be the explanation why env didn’t work, but .env does?
Hi sorry for the late reply. That’s the wrong location. .env works there because that’s how we do development (it looks for the file relative to the current directory). But you shouldn’t write to /var/www/ood because it’ll get overwritten on the next install.
/etc/ood/config/apps/myjobs/ is the directory you should use for configurations (specifically /etc/ood/config/apps/myjobs/env for the env file and the directory /etc/ood/config/apps/myjobs/initializers for initializers).
I was also able to quickly confirm that env worked with OOD_DATAROOT="/home/$USER/ondemand/data/sys/other-myjobs-location/".
Thank you so much for your reply as always!
For production, we have everything in /etc/ood/config/apps - in my development instance I was using /var/www/ood/ for testing purposes only, and your explanation of .env in that case makes sense.
Oh I see! Yea so here’s my workflow. If you’ve enabled development, you can work in your home directory on a development version of the app, without having to become root and potentially break things for other users (or developers)
work on things in my ~/ondemand/dev/. Here you can safely use a .env and maybe work on an initializer in config/initializers.
When we’re ready with that we can deploy them to a pre-production environment where we can be sure that they work in a production setting (deploying files to /etc)
deploy into production
Either way, it sound’s like you’re working on your pre-prod/dev environment (2) so you should likely do the same as production, deploy your configurations to /etc and not worry about /var/www/ood. Hope that helps!
