search

UCLALibrary / packer-samvera

A build of Samvera/Hyrax using Packer and the 'ansible-samvera' roles
BSD 3-Clause "New" or "Revised" License
1 stars 3 forks source link

Synchronize dev and prod Fedora environmental variables #64

Open ksclarke opened 5 years ago

ksclarke commented 5 years ago

Having a separate 'prod' and 'dev' fedora environment on the dev box causes problems. On that machine, we want there to be just 'test' and another Fedora node/context/environment. In fact, on our servers it's also fine that there is only one Fedora node/context/environment (the production one).

We need to make some changes to the Ansible roles to synchronize.

Add to templates/dotenv_config.j2:

FEDORA_BASE_PATH={{ fedora_base_path }}

Add to defaults/main.yml:

fedora_base_path: "{{ project_name }}"

This will make the Fedora node/context/environment be 'californica' instead of 'prod'.

We also need to add to README.md documentation about setting the FEDORA_BASE_PATH variable. It exists in the californica code base already but is new to our Ansible roles.

mark-dce commented 5 years ago

@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.

ksclarke commented 5 years ago

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.

mark-dce commented 5 years ago

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?