# A rough idea on specifying resources based on ansible\_\* vars **URL:** \ **Category:** Ansible Project\ **Tags:** ubuntu\ **Created:** [October 1, 2013, 9:47pm UTC](https://forum.ansible.com/t/a-rough-idea-on-specifying-resources-based-on-ansible-vars/13593 "2013-10-01T21:47:41Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Mark\_Casey](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@Mark\_Casey](https://forum.ansible.com/u/Mark_Casey)\ **Post date:** [October 1, 2013, 9:47pm UTC](https://forum.ansible.com/t/a-rough-idea-on-specifying-resources-based-on-ansible-vars/13593/1 "2013-10-01T21:47:41Z")
Hello, I had an idea with regards to a common syntax (or a filter, if you will) that would have ansible auto-select items in playbooks based on existing vars like ansible\_os\_family. I was wondering if (as I’m still pretty new here) this is something already in the works, is already done better in other ways, or whether it would be worth discussion. Essentially, as long as ansible is keeping track of all of these parameters why can’t a playbook use them to intelligently select which files or parts of a playbook to pay attention to. Perhaps something like “ansible\_os\_family:ansible\_distribution:ansible\_distribution\_release:ansible\_distribution\_version:FOO”? and simply leaving out the irrelevant bits? _ **Example 1 - “autosource” option to copy module, instead of source** _ **Files directory** : luser@new12:~$ ls -l foo/roles/files/ total 8 -rw-rw-r-- 1 luser luser 1015 Oct 1 15:44 Debian::::sshd\_config -rw-rw-r-- 1 luser luser 985 Oct 1 15:45 Debian:Ubuntu:precise:12.04:sshd\_config **Task snippet** : - name: Pick a file based on ansible\_\* vars copy: autosource=sshd\_config dest=/etc/ssh/sshd\_config **Result:** Running through with any OS in the Debian family besides Ubuntu precise 12.04 would get you the first, more generic config file, while running that particular version of Ubuntu (which we’ll pretend has some sort of bug that requires an option be removed from the config) would get the second config file. _ **Example 2 - handler intelligence** _ **Playbook snippet:** tasks: - name: Change a config file lineinfile: dest=/etc/some\_service/config regexp=“^anoption” line=“anoption no” state=present notify: Restart some\_service handlers - name: Restart some\_service Debian:::: service: name=sservice state=restarted - name: Restart some\_service Debian:Debian:lenny:: # sserviced in older service: name=sserviced state=restarted - name: Restart some\_service Debian:Ubuntu:hardy:: # sserviced in older service: name=sserviced state=restarted **Result:** Hardy and Lenny are handled differently than all the others. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [October 1, 2013, 11:11pm UTC](https://forum.ansible.com/t/a-rough-idea-on-specifying-resources-based-on-ansible-vars/13593/2 "2013-10-01T23:11:13Z")
Actually this is something you can do already with the “group\_by” module, but I think we could provide better ways to surface it. See “group\_by” in the module docs for how this works. This is something I was already planning for as second thing to do after we start recording facts to a pluggable backend. I’d probably guess the syntax should be - hosts: whatever\_groups when: - ansible\_os\_family == “Debian” - foons \> sporks - not emergency\_mode Etc And if the host didn’t meet the criteria, it would get pulled out of the group. There’s nothing to say this has to wait for fact caching though. ---
**Author:** ![Mark\_Casey](https://avatars.discourse-cdn.com/v4/letter/m/b4bc9f/32.png) [@Mark\_Casey](https://forum.ansible.com/u/Mark_Casey)\ **Post date:** [October 2, 2013, 7:56pm UTC](https://forum.ansible.com/t/a-rough-idea-on-specifying-resources-based-on-ansible-vars/13593/3 "2013-10-02T19:56:38Z")
Very cool. Thanks for your response. Mark