Synchronous Bootstrap

[Tim Penhey]

On 04/12/13 03:49, Andreas Hasenack wrote:
> On Tue, Dec 3, 2013 at 12:41 PM, William Reade
> <william.reade at canonical.com <mailto:william.reade at canonical.com>> wrote:
> 
>     On Tue, Dec 3, 2013 at 12:49 PM, Andreas Hasenack
>     <andreas at canonical.com <mailto:andreas at canonical.com>> wrote:
> 
>         On Tue, Dec 3, 2013 at 4:31 AM, Andrew Wilkins
>         <andrew.wilkins at canonical.com
>         <mailto:andrew.wilkins at canonical.com>> wrote:
> 
>             Ahoy,
> 
>             Just wanted to inform everyone that synchronous bootstrap
>             has landed on trunk. If you've got any scripts that
>             bootstrap an environment and expect it to chug away in the
>             background, then some script changes will be necessary.
> 
> 
>         Why not introduce this behavior via a switch to the existing
>         bootstrap command? Something like:
> 
>         juju bootstrap --wait
> 
>         Then existing scripts wouldn't break.
> 
> 
>     Followup commands always waited for bootstrap to complete before
>     they'd actually complete; the only negative impact should be that
>     *if* you were expecting to do independent work in parallel with a
>     bootstrap, that work will no longer be parallel. I'm very reluctant
>     to maintain multiple code paths for bootstrap, especially given the
>     many drawbacks of async bootstrap (lack of feedback, difficulty of
>     diagnosing failure, unnecessarily complex behaviour communicating
>     secrets to the environment) -- are there cases we've missed in which
>     this change will actually stop anything working?
> 
> 
> Don't get me wrong, I love synchronous bootstrap. I advocated for it a
> long time ago. I was just wondering about backwards compatibility, and
> how much do we promise to keep it at this stage.
> 
> This is the right time to try it (trunk) out, and if there are ill side
> effects we will catch them in time. For starters, it will be interesting
> if the CI setup will need any changes because of this.

I'd really not like to see it as a flag.  One of the benefits we have
with synchronous bootstraps is that it becomes much more obvious when
there are issues like having an old mongo (which is one of the biggest
issues new users have running behind closed networks), and issues
starting.  Also having a controlled place to upload the secrets instead
of having that code added by the second juju command.

It makes the code cleaner, easier to follow bootstrap, less user surprises.

So I am a massive -1 on a flag to switch between async/sync bootstrap.

Tim