MaaS provider should expose the bootstrap timeout options. #18
Conversation
|
LGTM although I wonder if we should also change the default for MAAS if 600 is never going to be enough? |
| # bootstrap-timeout: 600 | ||
|
|
||
| # bootstrap-retry-delay time between attempts to connect to an address, in seconds. | ||
| # bootstrap-retry-delay: 5 |
There was a problem hiding this comment.
If it's just the bootstrap that's slow (and that's addressed by bootstrap-timeout) why are bootstrap-retry-delay and bootstrap-addresses-delay also included? Is there something special about MAAS that means it makes sense to also show bootstrap-retry-delay and bootstrap-addresses-delay here?
|
Hey @mjs , In fact, this MR is just a cosmetic change, the real change would be to double ( 1200 sec ) the bootstrap-timeout. |
|
Well, if 20min is a good day, then it sounds like we actually need to set I think it would be reasonable to only expose bootstrap-timeout by default, John On Thu, Jun 5, 2014 at 5:23 AM, Jorge Niedbalski notifications@github.com
|
|
I agree we should expose the timeout setting for all providers; but shouldn't we just have the maas provider set a longer default if there's nothing specified in the raw data? |
Updated bootstrap-timeout to 1800 secs by default on MAAS provider.
|
@jameinel , i leave the bootstrap-timeout: 1800 by default. Thanks. |
|
@fwereade isn't just including a higher value in the default configuration file almost as good as encoding a higher default in the provider implementation? |
|
@mjs almost as good, yeah, but it's still just one more thing to remember (and type) when adding an env from scratch; not to mention one more thing to read when looking at an environment config. And all this is in service of something that should work anyway. Also ISTM (given that it's globally applicable) there'd be something subtly misleading about putting it in the sample maas config but not elsewhere... and putting it everywhere definitely seems like celebrating it beyond what it deserves. |
|
Leaving this variable exposed on the configuration boilerplate with the 1800 secs value fixes my initial issue. The question about what a good default value should be set, which is provider-dependent goes one step further on the same direction. How we should proceed? Suggestions? |
|
Just bootstrap-timeout option will be exposed, until this default value is increased on a per-provider basis.
|
Hello @fwereade , I modified this pull request to just expose the boostrap-timeout option in the boilerplate file. I pointed your comment on the public launchpad bug (https://bugs.launchpad.net/juju-core/+bug/1314665) moving that to 'Confirmed' , waiting for a juju-core team solution for having provider specific chosen configuration defaults. Thanks. |
|
Thanks Jorge! LGTM. |
|
|
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Merging failed |
|
|
|
Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju |
|
Build failed: Merging failed |
MaaS provider should expose the bootstrap timeout options. Most of the MAAS deployments takes longer times, in fact a install with d-i typically takes around 20 minutes on a good day. Would be a good thing to at least have the timeout settings exposed ( commented ) for being noticed by all users. Please see reference LP: #1325891
Rootfs provider/pool, various improvements
document use of gopkg.in
Provide a basic 'juju status' implementation for CAAS models
get-bundle-changes: print all errors when the given bundle is not valid.
Most of the MAAS deployments takes longer times, in fact a install with d-i typically takes around 20 minutes on a good day.
Would be a good thing to at least have the timeout settings exposed ( commented ) for being
noticed by all users.
Please see reference LP: #1325891