ssh timeout for bootstrap could be configurable

I think this is irrelevant now that https://code.launchpad.net/~axwalk/juju-core/waitssh-no-conn-timeout/+merge/198658 is merged in. Can we close this?

The maas lab reports that the 10 minute bootstrap limit is not enough time. They are currently looking at a hack to the code to give Juju enough time to start on maas + openstack. If we don't want this configurable, then some providers/substrates need different times.

Btw, there's no openstack involved. It's juju bootstrap on MAAS that takes longer than 10 min in the MAAS QA lab. With the timeout increased to 30 minutes, bootstrap proceeds further but I couldn't confirm that it actually finishes because my compiled version was compiled on Trusty and I was deploying on Precise. For this reason, --upload-tools fails at some point later on in the bootstrap workflow. Curtis gave me another workaround to use the --metadata-source option so the MAAS instance can download the juju tools from that source instead of searching for them in S3 (the lab doesn't have access to that). Today I'll give it a try again, maybe by setting up a proper simplestreams mirror for the MAAS lab and will report back. I think Curtis have enough details from our IRC conversation to file a proper bug regarding the use of --metadata-source in a network without wide access to the Internet. Thanks a lot for raising the importance of this bug.

It's been pointed out to me that there are machines in Canonical's Boston DC that take 10 minutes to *POST*. I'd suggest at least 1h if we're not going to have something configurable.