We're inconsistent in how we handle performing actions along the lines of For X Satellite version(s) perform Y action. Currently, some data/configuration comes from the vars file for the given Satellite version. In other cases we have things like this in the playbook:
# due to support for remote databases in 6.4+ the postgres user (and server) may be missing
- name: Install postgresql-server
yum:
name: "postgresql-server"
state: latest
when: satellite_version in ["6.5", "6.6", "6.7"]
This pattern means that each time there's a new Satellite version we need to review all of the tasks and make sure to update the satellite_version array as necessary which means we are going to miss things. The solution is to add additional configuration in the vars files. For the above example we could do something like below in roles/satellite-clone/vars/satellite-X.yml:
When we release a new Sat version and add support here the best case scenario is that we copy the vars file from the previous version, make any necessary edits, and not have to worry about doing a full-fledged review of the playbooks themselves.
We're inconsistent in how we handle performing actions along the lines of For X Satellite version(s) perform Y action. Currently, some data/configuration comes from the vars file for the given Satellite version. In other cases we have things like this in the playbook:
This pattern means that each time there's a new Satellite version we need to review all of the tasks and make sure to update the
satellite_version
array as necessary which means we are going to miss things. The solution is to add additional configuration in the vars files. For the above example we could do something like below inroles/satellite-clone/vars/satellite-X.yml
:Then the playbook can become:
When we release a new Sat version and add support here the best case scenario is that we copy the vars file from the previous version, make any necessary edits, and not have to worry about doing a full-fledged review of the playbooks themselves.