# Template testing **URL:** \ **Category:** Ansible Project\ **Tags:** ansible-project\ **Created:** [December 2, 2012, 8:57pm UTC](https://forum.ansible.com/t/template-testing/12115 "2012-12-02T20:57:43Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [December 2, 2012, 8:57pm UTC](https://forum.ansible.com/t/template-testing/12115/1 "2012-12-02T20:57:43Z")
Ok, so please explain what you are trying to achieve here, with an examples of how the user would go about using it? (Templating in /usr/bin/ansible (not playbook) is something we don't do anymore because it doesn't gather facts, nor do we want it to gather facts, because it would be an unneccessary step) --Michael ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [December 2, 2012, 8:59pm UTC](https://forum.ansible.com/t/template-testing/12115/2 "2012-12-02T20:59:33Z")
Somehow I missed your "part 2" earlier, yeah, this used to be something we could do, long ago. Sorry about that. We are not really interested in enabling this in /usr/bin/ansible due to the fact steps and not having as many variables available. It would be confusing because many people would want to supply variables defined in playbooks for testing on the CLI, and they wouldn't be there for /usr/bin/ansible. In all, I think it's much simpler if this is not a feature, and if you want to test, you just test your playbook on a dummy host. ---
**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\ **Post date:** [December 2, 2012, 9:09pm UTC](https://forum.ansible.com/t/template-testing/12115/3 "2012-12-02T21:09:27Z")
Or make a template-debuging playbook using a dest= that points to a local temporary directory using local\_action. Shouldn't be that hard either. ---
**Author:** ![Anastasis\_Andronidis](https://avatars.discourse-cdn.com/v4/letter/a/7cd45c/32.png) [@Anastasis\_Andronidis](https://forum.ansible.com/u/Anastasis_Andronidis)\ **Post date:** [December 3, 2012, 1:49pm UTC](https://forum.ansible.com/t/template-testing/12115/4 "2012-12-03T13:49:56Z")
Hello again, wouldn’t be useful for a user to be able to run any available task that he has on a playbook, with /usr/bin/ansible? I think that a feature like this would give great power to the end user for debugging purposes and not only. e.g. We (me and my team) have a use case that we need to run only 1 command to 100 hosts to update a service. We also believe that to make a playbook to run only 1 task is over-kill. We also have lots of templates that we want to watch them before we deploy them. Making a playbook, again, is too much for our needs. I also believe that we can do that (make /usr/bin/ansible working as /usr/bin/ansible-playbook) without increasing the complexity of code and maintainability. As I understand the needed variables would come from 4 different places: 1. facts 2. group\_vars 3. host\_vars 4. included files /usr/bin/ansible would provide all those variables if we connect inventory class with steps 2,3,4 and if we give a flag (/usr/bin/ansible --gather-facts) for step 1. I believe that a change like this would give great modularity to the code. Right now, steps 2,3,4 are bound with play.py. By bounding steps 2,3,4 to inventory class, playbook class and ansible class could access host,group and file variables through methods like: inventory.get\_group\_vars(host) , inventory.get\_host\_vars(host), inventory.get\_file\_vars(). This means that both classes(ansible, ansible-playbook) will no longer have to manage finding and loading vars or facts, they will only address inventory and get what they need. Also, if we also add get\_facts\_for\_host(host) to inventory class, we can make /usr/bin/ansible ask for facts only if the user needs it (e.g. for debug purposes or wtvr). I believe that both Runner, Playbook, Play and Task classes should only do scheduling, module and task calling, argument cleaning etc. and not managing or caching: variable files, getting facts, reading variables, etc. I think I can work on this a little bit, so I can show you some code about that and you can comment it. Do you believe that something like that would be useful? –Anastasis ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [December 3, 2012, 2:03pm UTC](https://forum.ansible.com/t/template-testing/12115/5 "2012-12-03T14:03:04Z")
I've given reasons already why it doesn't make sense for templates. The other stuff, I really don't want to even think about, and we won't be accepting patches. AFAIK this should be fine though -- most other config tools can't template from a non-recipe based CLI either. Not really interested in refactoring for this either. I'm really looking for the core to stabilize and the future of Ansible is largely in evolution of plugins and modules, and eventually, those in core will also stabilize to where the future work just revolves around keeping them working with distribution changes. We want to get to the point where \*less\* happens in Ansible month to month in the core, and especially as this release crosses December, I want to keep it small. This is 1.0, I think that's an ok theme. It is time for this to stop being bleeding edge and to approach doneness. --Michael ---
**Author:** ![Daniel\_Hokka\_Zakriss](https://avatars.discourse-cdn.com/v4/letter/d/f05b48/32.png) [@Daniel\_Hokka\_Zakriss](https://forum.ansible.com/u/Daniel_Hokka_Zakriss)\ **Post date:** [December 3, 2012, 2:14pm UTC](https://forum.ansible.com/t/template-testing/12115/6 "2012-12-03T14:14:22Z")
Anastasis Andronidis wrote: > Hello again, > > wouldn't be useful for a user to be able to run any available task that he > has on a playbook, with /usr/bin/ansible? > > I think that a feature like this would give great power to the end user > for > debugging purposes and not only. e.g. We (me and my team) have a use case > that we need to run only 1 command to 100 hosts to update a service. We > also believe that to make a playbook to run only 1 task is over-kill. We > also have lots of templates that we want to watch them before we deploy > them. Making a playbook, again, is too much for our needs. "Making a playbook" is two lines in addition to what you actually want to do. I hardly think that is "too much". > I also believe that we can do that (make /usr/bin/ansible working > as /usr/bin/ansible-playbook) without increasing the complexity of code > and > maintainability. > > As I understand the needed variables would come from 4 different places: > > 1) facts > 2) group\_vars > 3) host\_vars > 4) included files > > /usr/bin/ansible would provide all those variables if we connect inventory > class with steps 2,3,4 and if we give a flag > (/usr/bin/ansible --gather-facts) for step 1. > > I believe that a change like this would give great modularity to the code. > > Right now, steps 2,3,4 are bound with play.py. By bounding steps 2,3,4 to > inventory class, playbook class and ansible class could access host,group > and file variables through methods like: inventory.get\_group\_vars(host) , > inventory.get\_host\_vars(host), inventory.get\_file\_vars(). This means that > both classes(ansible, ansible-playbook) will no longer have to manage > finding and loading vars or facts, they will only address inventory and > get > what they need. > > Also, if we also add get\_facts\_for\_host(host) to inventory class, we can > make /usr/bin/ansible ask for facts only if the user needs it (e.g. for > debug purposes or wtvr). Inventory is entirely the wrong place for everything but host and group vars. vars\_files is a playbook construct, as is facts gathering. It seems to me you should just write a script that generates a minimal playbook and runs it instead of bastardizing the internal APIs for it. Daniel ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [December 3, 2012, 2:44pm UTC](https://forum.ansible.com/t/template-testing/12115/7 "2012-12-03T14:44:44Z")
Here's a rough sketch of a playbook template tester. test\_template.yml - hosts: all   tasks:      - template: src=$src dest=$dest test\_template.sh: ansible-playbook test\_template.yml -i "127.0.0.1," -c local --extra-vars "src=$1 dest=/tmp/template.out" cat /tmp/template.out