Always sleep on packer provisioning?

Question

On my exploration of Packer I wonder the following:

The docs state (as part of the getting started steps where a Ubuntu image is provisioned to AWS):

Note: The sleep 30 in the example above is very important. Because Packer is able to detect and SSH into the instance as soon as SSH is available, Ubuntu actually doesn't get proper amounts of time to initialize. The sleep makes sure that the OS properly initializes.

It shows an example where a shell provisioner (inline) is the first provisioner to kick in.

Do you always need to sleep 30 before any provisioner is to start, in particular:

• When I start the provisioning block with a file provisioner, does it automatically wait until the OS properly initializes?
• When I run a script/scripts shell provisioner instead of an inline block of commands, do I need to start the first script with sleep 30?

If so, would a general suggestion be that you always put this on top of your provisioning block:

"provisioners": [
{
    "type": "shell",
    "inline": [
        "sleep 30"
    ]
},
{...}]

Answer 1

You can run without the sleep, but particularly on AWS it's going to be a crapshoot whether it works or not. Packer builds can be long and complex, and some sleep here and there can greatly improve your success rate. You don't have to run a sleep before every provisioner though, just the first one. After that the OS is up and everything should be running along nicely.

I don't use the sleep command before apt, but my packages were failing all over the place. I'm using the Packer AWS ebs builder. There's a statement in the docs that solved my problems with a very similar strategy - it polls against cloud-init to see that it has finished; cloud-init being the aws init built into the Ubuntu ec2 images produced by canonical.

{
"type": "shell",
  "inline": [
    "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Waiting for cloud-init...'; sleep 1; done"
  ]
}

So it's not strictly necessary, but you'll find that once you have a working build with Packer, you still will want to improve the reliability of your scripts and other provisioners with timing and retries. A failed build on Packer is a big time waster.