Global env vars to be used by all OOD apps (MVP)

[ericfranz]

Add to the nginx_stage config an optional envvars hash to set values for things like:

• OOD_DASHBOARD_TITLE
• OOD_PORTAL

This would be set in the PUN config at the top https://github.com/OSC/nginx_stage/blob/a4dd339c2c3fc49ba1ea18d0f4abdeab0db4edeb/templates/pun.conf.erb#L2 and support env vars that would be set in one place, made available to all apps in all Passenger environments (dev and prod), and have values that were static (not dynamically generated).

We also discussed:

A. Adding default values for well known env vars i.e. OOD_PORTAL and OOD_DASHBOARD_TITLE

• Benefit: non-ood_appkit/rails apps like file explorer, ps example app, etc. could use the env vars directly without using guard clause to provide default value
• Drawback: could not be overridden using default functionality of dotenv files; as a result we couldn't provide default values for OOD_DASHBOARD_TITLE without introducing a "breaking change". One solution would be to use a different env for the dashboard title i.e. DASHBOARD_TITLE; drawback of that is it requires an update to ood_appkit and thus all the apps that use it; DASHBOARD_TITLE also doesn't follow the convention of other env vars for apps in OOD_APPKIT, though customization of those apps titles aren't in use.

Conclusion: I'd hold off on setting defaults initially for OOD_DASHBOARD_TITLE so the changes for this issue can stay isolated to just a change in nginx_stage. Could probably set default for OOD_PORTAL, though if this happens deployment to production will be more difficult because we will need to couple the deployment of this nginx_stage change with the puppet config change to the nginx_stage config file for the AweSim portal deployment. Otherwise apps that rely on dotenv files setting OOD_PORTAL might have those values ignored i.e. https://github.com/OSC/ood-myjobs. Thus IMHO it would be best to avoid setting default values for now so we can deploy this change to production sooner and slowly move into making use of the new env vars in our AweSim and OnDemand deployments.

B. Adding app specific env vars (i.e. only usr and sys apps for production env)

• Could be implemented using Passenger 4's passenger_set_cgi_param and Passenger 5's passenger_env_var.
• Benefit: could add env vars that should only affect production apps
• Drawback: changes to env vars (adding more or setting values) could result in
• Drawback: having env vars that only affect production could be a negative for development purposes

Conclusion: Table this for later when we have a good use case.

C. Supporting dynamic variables

Conclusion: Table this for later when we have a good use case.

[nickjer]

Was just now looking back at this and had a question. How would a developer override a global env var? For instance, what if I wanted to test a different OOD_DASHBOARD_TITLE. If it is global, then the dotenv gem won't read it from .env.local.

In the case of app configs we decided that only production apps would read app configuration under /etc/ood/config/apps/.... And that development/test apps would only read configuration local to the app. Using global env vars to describe app configuration unfortunately breaks this convention.

[brianmcmichael]

The app(s) would probably need to be updated to allow for local envars. Eric's comment expresses that as a drawback.

It looks to me like a workaround would need to be coded, like:

ENV['USER_DASHBOARD_TITLE'] || ENV['OOD_DASHBOARD_TITLE'] || default

But that would add more envvars to the process and need to be documented in the individual apps.

[ericfranz]

How would a developer override a global env var?

A custom initializer. Dotenv#overload sets a different value.

And that development/test apps would only read configuration local to the app. Using global env vars to describe app configuration unfortunately breaks this convention.

Running in "test" won't pick up the configuration because it won't go through NGINX - just rake tasks. Dev would, however.

Like we discussed in the past, we would only want to set global config variables for things that really were global to both dev and prod, specific to the portal, such as OOD_PORTAL and OOD_DASHBOARD_TITLE.

I imagine there could be a place in the future for app config specific, but only if app configs were auto-generated like the nginx config, and we can't do that right now unless we introduced a different type of persistence to OnDemand (i.e. something that could indicate which paths/uris sto create app configs for).

For convenience, we could optionally update the Configuration object we use to load dotenv files to include loading .env.development.overload etc. to actually call the overload function.