Juju 2.0: default bootstrap-timeout insufficient for physical machines

[Chad Smith]

For juju 2.0 can we get this bootstrap timeout bumped to a bit higher default to account for physical hardware?

For cloud targets 600 seconds seems a reasonable expectation for bootstrap-timeout. but, when working through MAAS to manage machine boots and BIOS POSTs, we currently cross the default bootstrap-timeout giving us the dreaded

ERROR failed to bootstrap environment: bootstrap instance started but did not change to Deployed state: instance "/MAAS/api/1.0/nodes/<node-UUID>/" is started but not deployed.

For generic physical hardware through MAAS this default bootstrap-timeout of 600 seconds doesn't seem sufficient. With our relatively stock hardware ProLiant DL360s we frequently spend 2-3 minutes between power on and PXE netboot request and 5 mins on curtin install. This doesn't leave a lot of room for proxy delays or larger systems.

Can juju 2.0 to increase the default timeout so customers don't have to jump to --config options for their bootstraps when using MAAS and physical hardware?

[Eric Snow (ericsnowcurrently)]

Perhaps the MAAS provider could override the default bootstrap-timeout to a more appropriate value. This would be a more palatable solution than increasing the default for all providers.

[Chad Smith (chad.smith)]

I was hoping this was the direction the team might think to go, but didn't want to prescribe the solution in the bug report. +1

[Anastasia (anastasia-macmood)]

PR: https://github.com/juju/juju/pull/5638