Collecting setup facts from other servers when using --limit

[Michael Peters]

I have a playbook that sets up the application configuration on a
server in a cluster. This configuration is based on other servers in
the cluster and uses hostvars to great effect in the templated
configuration. I'm really happy at how easy ansible make that. To make
that work so that the facts about the other hosts are gathered I have
an empty play at the top of these playbooks that looks something like
this:

# just gather facts from these groups
- hosts: group1:group2:group3
tasks:

# now do the real work
- hosts: group4
tasks:
# lots of tasks

This seems a little weird that there's not an explicit way to gather
facts (it just a side effect, but it works fine so no biggie.

That's the preamble... The awkward part is when I want to add a new
server to this cluster and I want to run a playbook against just one
host of the group (the new server). Normally I could just use a
--limit server8 or something, but then this skips the fact gathering
step implicit in the empty tasks at the beginning of the playbook. So
instead I have to do something like:

--limit server8:group1:group2:group3

Or (slightly shorter but more opaque)

--limit '!group4&server8'

I'm trying to train myself to remember to do one of these, but I have
to train my team too. It would be nice if my playbook had a way of
explicitly gathering facts that wasn't skipped by a --limit arg (more
control in the playbook and less need for command line args) and then
I could just do the more intuitive

--limit server8

Am I doing it wrong? Or is this a pain others feel?

--
Michael Peters

[Michael DeHaan]

This has come up once or twice.

When limiting, you can't get facts from other hosts.

The solution is to not use --limit and instead do:

hosts: "mygroup:{{ limit_spec }}"

and pass "-e limit_spec=what_I_would_have_passed_to_limit"

This allows patterns like:

- hosts: all

  tasks: []  # gather facts

- hosts: mygroup:{{ limit_spec }}"

  tasks:

     -

And you can still rely on the previous gathered steps without limiting execution to just those hosts.

For bonus points, take the colon off...

- hosts: mygroup{{ limit_spec | default('') }}

And then on the CLI:

-e "limit_spec=:&webservers"

And if no limit is specified, it works like you would want.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJQqANdp8-XY5BjSh_dRyUWRnKtcQOfoyE_%2Bam0O-5x5fEdR-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Peters]

Thanks for the additional options. But doesn't it seem weird that you
should/shouldn't use --limit based on the implementation details of
the playbook? Should the person who is running the playing have to
know about the inner workings of the playbook file in order to know
whether to use --limit or not? Just seems prone to error and like
there should be a better way. Maybe it's a more explicit way of
gathering facts, maybe it's something else.

> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyz1iuqE29wA_gS6aPT0XEnuQbJiEOcDaatTt-ONWPo0A%40mail.gmail.com.

[Michael DeHaan]

" But doesn't it seem weird that you
should/shouldn't use --limit based on the implementation details of
the playbook?"

Depends what you want limit to do.   It's kind of a damned if you do/don't, sort of thing.

I suppose we could make a smart exemption for a single play with no tasks other than fact gathering, so that --limit doesn't apply to them, but some people won't like that.

Thus it really is a request for fact caching, which we are not quite ready for yet -- (requires everybody to stop wanting other things so we can catch some breaths, etc) :)

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJQqANcv2dro%3D%2BRzqcHmJnqraJohsif05MFLCC%2BFWiyuuOdGPw%40mail.gmail.com.