Redis error on `centos` branch when installing on Ubuntu

[mark-dce]

I'm running a local Vagrant build camper that should build a development system to run the hydra tutorials.

When I merge in the centos branch changes, I get the following ansible errors:

TASK [sufia_dependencies/install : redis and resque] ***************************
included: /Users/mark/Documents/workspace/_no_backup/deployinghydra/camper/ansible-hydra/roles/sufia_dependencies/install/tasks/redis_resque.yml for default

TASK [sufia_dependencies/install : enable epel repo for redis on CentOS] *******
skipping: [default]

TASK [sufia_dependencies/install : install redis for CentOS] *******************
[DEPRECATION WARNING]: Skipping task due to undefined Error, in the future this
 will be a fatal error.: 'redis' is undefined.
This feature will be removed in 
a future release. Deprecation warnings can be disabled by setting 
deprecation_warnings=False in ansible.cfg.

TASK [sufia_dependencies/install : run redis] **********************************
fatal: [default]: FAILED! => {"failed": true, "msg": "'redis' is undefined"}
    to retry, use: --limit @build_camp_box.retry

PLAY RECAP *********************************************************************
default                    : ok=28   changed=21   unreachable=0    failed=1   

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

[mark-dce]

@acozine it looks like you might need to add a default for the redis variable used here: https://github.com/curationexperts/ansible-hydra/blob/centos/roles/sufia_dependencies/install/tasks/redis_resque.yml#L20-L22

If the redis server has different names on Centos vs. Ubuntu, it might be simpler just to add a test for each OS and list the name explicitly - that might be clearer than having to dereference which

To finish my test, I'm just changing lines 20-22 to read

- name: run redis
  service: name=redis-server state=started  # no curly braces around redis-server
  become: yes

[acozine]

Drat, I missed setting a default - all the defaults are set for Ubuntu.

To me, using variables seems cleaner and faster than adding a task for each OS. A variable gives us one task per task, with an acknowledgment of the OS-level differences. I used this pattern in a number of places (for example, the names for the ssh service and the apache service also differ).

However, using variables does make the roles less ignorance-proof. I'll think about this for a bit.

[mark-dce]

It's definitely a balance between elegance once you know what's going on vs. the transparence of seeing exactly what's happening all in one place (with the redundancy and non-executing code that implies).

As it's set up now, It did take me about 10 minutes to do a few searches and walk through everything to convince myself that there was a variable missing and not something set up incorrectly on my end.

I'd ask yourself this: would your future self prefer the refined version of a single task with variables appropriate to each OS (potentially having to take extra steps to figure out the actual value of those variables). Or would your future self prefer to have two largely similar hunks of code with explicit settings right in front of you (knowing that you have to ignore every other one because it won't be in effect for whichever OS you choose). I's say go with whichever you think will be easiest to get your head wrapped back around when you haven't looked at it for 6-12 months.

[acozine]

Agreed fix is in #173