Comment 2 for bug 984640

First off, I agree that we should see errors much closer to our commands in juju, for that reason, I'm confirming this bug.

I'm not sure preflighting is actually desirable in this case.

Given Juju's current architecture which favors asynchronous methods and "retry forever", I don't think its conceivable that this can be done without compromising. Juju should just keep trying to deploy with the constraints dictated until the operation succeeds.

I think at some point we're going to need to have more interactivity in the juju client. I think that should come along with the implementation of a REST API.

Basically everything you do needs a context of a command set. When you deploy, you should get a context, and then be able to watch for activity regarding that context. Logs, errors, status changes, etc, should all push reports of their activity to that context as long as you keep it open. This way you can run 5 commands all at once (call it a stack if you will), and then watch a log of the things that happen.

We're a long way from that, but I don't think we can emulate the desired effect without bolting things on at the wrong level. Too much pre-flighting would make it hard to perform operations in an asynchronous, independent fashion.

For now, effective use of 'debug-log' at all times is the recommended workaround.