Unsatisfied constraints are not reported back to the user

[Francis J. Lacoste]

If I use a constraint that can't be satisfied by the provider, the user has no way to detect the problem apart from looking at the provisioning agent log on the boostrap node.

In this particular case, I used juju deploy --constraints maas-name=oneiric mysql with the MAAS provider. There were no nodes with that name, but I could only find it by looking at the log and seeing that a 409 CONFLICT was returned by the MAAS server.

[William Reade (fwereade)]

This is an interesting one.

We can (and hopefully *will*) easily add the ability to preflight constraints before they ever leave the CLI; but we can't ever *guarantee* a successful launch by the provisioning agent (because, for example, someone could grab that machine in the interval between the preflight and the actual request).

Offhand, I suspect that `juju status` would be the right way to communicate this back -- so rather than just seeing "machine-state: pending" forever, you instead see "machine-state: launch-error" (With, perhaps, a launch-error field that only shows up if the machine's in that state?).

Independent of the preflighting, which is IMO a necessity anyway, would that be a reasonable way of communicating unpredictable problems?

[Clint Byrum (clint-fewbar)]

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.

[William Reade (fwereade)]

OK, I see your point; in this case it would be perfectly reasonable to try to deploy to "some-named-node" that you expect to become available soon (even if it isn't right now), and preflighting would kill that possibility.

Clearer communication of machine-launch errors in status still strikes me as a good idea, though, and I'm not entirely convinced that preflighting is actually a bad idea; I think I'd rather have it and to be able to turn it off selectively than leave it out forever.

I'm also very much on the fence about interactivity. I think I'd prefer:

  $ juju deploy mysql --constraints maas-name=bob
  ERROR "bob" is in use or does not exist
  $ juju deploy mysql --constraints maas-name=bob --shut-up-i-know-what-im-doing

...and just include the --shut-up flag in scripts, rather than have interactivity by default; that way an error in a script is actually communicated as an error (as opposed to blocking on user input forever). Except, hmm, we've kinda already made the opposite choice for host-key confirmation. Bah.

[Clint Byrum (clint-fewbar)]

This feels like a feature since we're discussing changing default behaviors. I'm not sure its appropriate to land this in galapagos. We're also in quite a time crunch for Galapagos, and I think this one needs some careful consideration.

Once we make the default to fail on pre-flight check, it will be a bug to move forward without a --force or --shut-up flag, and then we may find later that we in fact want scripts to always move forward rather than fail in this way.

[Martin Packman (gz)]

See also bug 828378 which is much the same issue.