On 04/12/13 03:49, Andreas Hasenack wrote: > On Tue, Dec 3, 2013 at 12:41 PM, William Reade > <william.re...@canonical.com <mailto:william.re...@canonical.com>> wrote: > > On Tue, Dec 3, 2013 at 12:49 PM, Andreas Hasenack > <andr...@canonical.com <mailto:andr...@canonical.com>> wrote: > > On Tue, Dec 3, 2013 at 4:31 AM, Andrew Wilkins > <andrew.wilk...@canonical.com > <mailto:andrew.wilk...@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 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
