default bootstrap timeout is too low for MAAS environments

[Jacek Nykis]

I was bootstrapping a MAAS environment and hit 10 minutes timeout:

Waiting for address
Attempting to connect to host.domain:22
ERROR bootstrap failed: waited for 10m0s without being able to connect: ssh: connect to host host.domain port 22: Connection refused
Stopping instance...
Bootstrap failed, destroying environment
ERROR waited for 10m0s without being able to connect: ssh: connect to host host.domain port 22: Connection refused

I can work around it using "bootstrap-timeout" configuration option but this default seems too low for MAAS environments. Many physical servers take few minutes to POST and after that they need to deploy OS.

It would be good to have longer timeout used for MAAS environments, 20-30 minutes will likely be enough for most deployments. Another solution could be to prompt user whether to wait a bit longer for bootstrap or give up.

[Curtis Hovey (sinzui)]

We know juju needs to set "bootstrap-timeout: 1800" or more bootstrap. Either the config "juju init" does the right thing, of the provider has a different timeout set.

From the docs.
Environments that need more time to provision an instance can configure 3 options the environments.yaml. MAAS environments often need to set bootstrap- timeout to 1800.

bootstrap-timeout (default: 600s)
bootstrap-retry-delay (default: 5s)
bootstrap-addresses-delay (default: 10s)

[Dave Chiluk (chiluk)]

To rough-quote a certain benevolent dictator, "make the corner cases just work, and the rest will fall into place".

Here's another vote for increasing the defaults.

[Jorge Niedbalski (niedbalski)]

+1 for increasing the defaults to a larger value.

[Jorge Niedbalski (niedbalski)]

Addressing @fwreaded comments on github pull request: https://github.com/juju/juju/pull/18

The bootstrap-timeout option will be exposed by default with value = 1800 secs, but this is not a definitive
fix for this issue for the following reasons:

1) the bootstrap timeout default is bad for maas, since this must be greater or equals to 1800 secs
2) there's no way for a specific provider to choose defaults for *Config-level values.

So, i will pass this bug responsibility to the juju-core team for implement a way for a specific provider to choose
default *Config level values.