bootstrapping nodes - when the setup module fails

Archives Ansible Project
1

Hi,

Is it possible to handle the initial ssh connection failure rather than bail out completely? Let me clarify why, maybe there’s a better way to do this.

I’ve got a wide variety of OS & cloud providers to test stuff against, and I’m slowly automating all of this. Bootstrapping in this case comprises ensuring we have a suitable python, adding root & ansible user ssh keys, sudo etc before normal ansible work. Currently I have a separate bootstrap script to get nodes off the ground, but what I really want is single `site.yml` to handle that as well.

I thought I could use the setup module to check if we need to bootstrap or not:

```site.yml

2

Take a look at this ec2 example: http://docs.ansible.com/guide_aws.html#example-4

The wait_for module is capable of delaying a play until some resource (ssh for example) becomes available.

3

Well, sort of. That waits for a port to become available, not trying to see if a username/password can already log in.

There’s nothing available to try a lot of random access credentials to see what works.

I’d recommend hosts get bootstrapped via a basic kickstart/preseed in most cases, but that’s just me.

4

Thanks, I accept I need 2 separate playbooks for this :frowning:

I've found however that `gather_facts=False` in the top-level playbook
doesn't seem to get propagated through to an individual role, and
AFAICT it's not possible to set that flag at a role level. So net
result is that it's not possible to disable fact-gathering in a
complex setup. The same declarations run just fine in a single
playbook.

See in line 34 of the playbook+role log, ansible insists on running
the setup module, and obviously fails as python is not yet present:
https://www.irccloud.com/pastebin/q3Ht1Llw

The same in a single playbook runs fine:
https://www.irccloud.com/pastebin/RpjehH2Y

Is this a bug, or expected behaviour?

5

“I’ve found however that gather_facts=False in the top-level playbook
doesn’t seem to get propagated through to an individual role,”

False.

Fact gathering runs before roles.

“AFAICT it’s not possible to set that flag at a role level.”

Because it’s a property of the playbook, yes. Also it doesn’t matter because the default is to gather facts, which is what you want 99.99% of the time. If you don’t, it just makes you wait a tiny bit. You enable or disable this at play level.

“So net
result is that it’s not possible to disable fact-gathering in a
complex setup”

False.

Now what you’ve pasted doesn’t really match my expectation of reality, so perhaps you have copy/pasted provisioning.yml or something?

You can totally do “gather_facts: false”.

6

TASK: [bootstrap | setup ]

This seems to indicate you have an explicit call to the setup module inside
the bootstrap role.

I have a simple bootstrap play I've used with FreeBSD, disabling
gather_facts: is all you need to use raw to install python with simplejson.

FYI, roles DON'T automatically gather facts, plays do, roles run tasks,
only if you create a explicit task that gathers facts will a role gather
them.

7

^^ bingo ^^

Aha… thanks both Brian & Michael very much.

I was completely mistaken about how tasks in roles are processed;
there's a roles/bootstrap/main.yml with a setup call in it, which as
per documentation is pulled in.

Sorry for the noise!

A+
Dave

8

Nice catch Brian!