Unsatisfied constraints are not reported back to the user
Bug #984640 reported by
Francis J. Lacoste
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pyjuju |
Triaged
|
Low
|
Unassigned |
Bug Description
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.
Changed in juju: | |
milestone: | none → galapagos |
Changed in juju: | |
milestone: | galapagos → honolulu |
Changed in juju: | |
milestone: | 0.6 → none |
Changed in juju: | |
status: | Confirmed → Triaged |
Changed in juju: | |
importance: | Medium → Low |
To post a comment you must log in.
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?