6545e3cf24
This revises the Greenwave config again, aiming to be as clear and efficient as possible. The major practical change here is we use fedora-* for the product_versions in the 'null' policy (wildcards like this have been allowed since Greenwave commit be9a5427 in 2018), and we use lists of decision_contexts instead of a single decision_context per policy (this has been allowed since 1.6.0), allowing us to combine two pairs of policies into single policies. I also revised the comments, policy names and file organization, taking advantage of these simplifications. We could make this even more efficient if policies could apply to multiple subject_types as well, but apparently they can't. I've filed https://pagure.io/greenwave/issue/609 for that. Using a wildcard for product_versions in the null policy will have the practical consequence that whenever a new Fedora release or dist shows up, if no policy has been prepared for it in advance, queries for it that match the other elements of the null policy will succeed rather than failing because no policy is found. i.e., practically speaking, Bodhi push queries will succeed rather than failing. I think this is what we want (since whenever that happens we just go ahead and add the identifier to the null policy), but it's worth noting. Signed-off-by: Adam Williamson <awilliam@redhat.com> |
||
|---|---|---|
| cache_plugins | ||
| callback_plugins | ||
| ci | ||
| files | ||
| filter_plugins | ||
| handlers | ||
| inventory | ||
| library | ||
| playbooks | ||
| roles | ||
| scripts | ||
| tasks | ||
| vars | ||
| .gitignore | ||
| .mailmap | ||
| .yamllint.yaml | ||
| .zuul.yaml | ||
| CONVENTIONS | ||
| master.yml | ||
| README | ||
| README.md | ||
| STYLEGUIDE | ||
Fedora Infrastructure
Welcome! This is the Fedora Infrastructure Ansible Pagure project.
Pull requests and forks can be made against this repository hosted at https://pagure.io/fedora-infra/ansible
This repository is also mirrored for production runs to https://infrastructure.fedoraproject.org/infra/ansible/ but this is the working repository where changes are made.
If you would like to help out with Fedora Infrastructure, see:
- https://fedoraproject.org/wiki/Infrastructure/GettingStarted
- https://fedoraproject.org/wiki/Infrastructure_Apprentice
Ansible repository/structure
files - files and templates for use in playbooks/tasks
- subdirs for specific tasks/dirs highly recommended
inventory - where the inventory and additional vars is stored
- All files in this directory in ini format
- added together for total inventory
group_vars:
- per group variables set here in a file per group
host_vars:
- per host variables set here in a file per host
library - library of custom local ansible modules
playbooks - collections of plays we want to run on systems
groups: groups of hosts configured from one playbook.
hosts: playbooks for single hosts.
manual: playbooks that are only run manually by an admin as needed.
tasks - snippets of tasks that should be included in plays
roles - specific roles to be use in playbooks.
Each role has it's own files/templates/vars
filter_plugins - Jinja filters
master.yml - This is the master playbook, consisting of all
current group and host playbooks. Note that the
daily cron doesn't run this, it runs even over
playbooks that are not yet included in master.
This playbook is usefull for making changes over
multiple groups/hosts usually with -t (tag).
Paths
The public path on batcave01 (our control host) for everything is /srv/web/infra/ansible
The private path on batcave01 (our control host) (which is sysadmin-main accessible only)
is /srv/private/ansible
In general to run any ansible playbook you will want to run:
sudo -i ansible-playbook /path/to/playbook.yml
(On batcave01, our control host)
Scheduled check-diff
Every night a cron job runs over all playbooks under playbooks/{groups}{hosts}
with ansible --check --diff. A report from this is sent to sysadmin-logs.
In the ideal state this report would be empty.
Idempotency
All playbooks should be idempotent. Ie, if run once they should bring the machine(s) to the desired state, and if run again N times after that they should make 0 changes (because the machine(s) are in the desired state). Please make sure your playbooks are idempotent.
Can be run anytime
When a playbook or change is checked into ansible you should assume that it could be run at ANY TIME. Always make sure the checked in state is the desired state. Always test changes when they land so they don't surprise you later.