Synchronize dev and prod Fedora environmental variables about packer-samvera HOT 3 OPEN

@ksclarke can you be more specific about "causes problems" in your first sentence? I don't quite understand the underlying problem here, so I'm not sure how much to interject, but DCE has moved away from naming services by project-name because it sometimes makes maintenance and documentation more complicated.

from packer-samvera.

For the dev box, the production and the development configs are the same, except currently with Fedora (where the /prod and /dev contexts still persist and cause problems when trying to do things like edit a record in the UI -- due to things being ingested as "dev" but served up via "prod"). We could just set both to /prod in the dev box Ansible build and that'd be fine (would resolve the immediate issue).

I just suggested the project name because on servers and the dev box we only have one context. Using the project name is a way to have a single meaningful Fedora context that's not distinguished as "prod" or "dev", which really are the names of the environment and more useful if you had both environments on a single machine (not the case for our servers or dev box).

I think that maintenance isn't an issue because we rely on Ansible to do our builds. I could see if things weren't automated how it might cause issues. I see the argument that documentation across many different Samvera projects is more complicated. We'll only have one Samvera though, unlike you all who have lots of clients.

from packer-samvera.

In reverse order - agreed, it's probably less of an issue to use the project name since you'll have fewer project names to work with, but you will need to remember to substitute project-name for dev when following any community documentation - probably not a biggie.

I'm confused why the application in the dev environment is serving things up under /prod fedora - I'm not sure you want to run your development workflow against a web server configured for production even on a VM. Rails makes lots of tuning to the "development" environment to prioritize a single user making real-time changes and the "production" environment to prioritize performant multi-user access with longer startup time. e.g. compare config.cache_classes and config.consider_all_requests_local = true in https://github.com/UCLALibrary/californica/blob/master/config/environments/development.rb and https://github.com/UCLALibrary/californica/blob/master/config/environments/production.rb

So, it sounds like somewhere something is assuming "RAILS_ENV=production"??? I think you really want your development work to be happening in an environment where "RAILS_ENV=development" on the VM. Does that make sense and does it help in this context any?

from packer-samvera.