" 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) :) On Tue, May 13, 2014 at 4:50 PM, Michael Peters <[email protected]>wrote: > 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. > > On Tue, May 13, 2014 at 3:52 PM, Michael DeHaan <[email protected]> > wrote: > > 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. > > > > > > > > > > > > On Tue, May 13, 2014 at 1:14 PM, Michael Peters < > [email protected]> > > wrote: > >> > >> 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 > >> > >> -- > >> 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 [email protected]. > >> To post to this group, send email to [email protected]. > >> 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. > > > > > > -- > > 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 [email protected]. > > To post to this group, send email to [email protected]. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyz1iuqE29wA_gS6aPT0XEnuQbJiEOcDaatTt-ONWPo0A%40mail.gmail.com > . > > For more options, visit https://groups.google.com/d/optout. > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/CAJQqANcv2dro%3D%2BRzqcHmJnqraJohsif05MFLCC%2BFWiyuuOdGPw%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyg9Jj5XvL%2BJnCvq4ePeXmwuU1jC%3DaYd5ppzVte8UnS-g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
