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
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.
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.
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:
/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
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
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
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