error when maas can't meet juju constraints is confusing and not helpful
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
Wishlist
|
Jeroen T. Vermeulen |
Bug Description
While trying to deploy landscape via MAAS and Juju, we are running into issues with juju constraints not being met by MAAS. Unfortunately, we have no indication of WHAT constraints were failed. Here's the output from the maas server:
ERROR 2014-01-29 11:52:38,522 maasserver #######
ERROR 2014-01-29 11:52:38,522 maasserver Traceback (most recent call last):
File "/usr/lib/
response = wrapped_
File "/usr/lib/
response = func(*args, **kwargs)
File "/usr/lib/
result = self.error_
File "/usr/lib/
result = meth(request, *args, **kwargs)
File "/usr/lib/
return function(self, request, *args, **kwargs)
File "/usr/lib/
raise NodesNotAvailab
NodesNotAvailable: No matching node is available.
As someone using maas and juju, this is entirely unhelpful as neither MAAS not Juju tell me what is wrong here.
MAAS should handle this error more cleanly and actually say what constraint was not met (even if it's a raw constraint and not pretty). Thus something like this:
ERROR: MAAS could not find a machine matching the constraint "mem=16GB"
Related branches
- Raphaël Badin (community): Approve
-
Diff: 265 lines (+184/-1)4 files modifiedsrc/maasserver/api.py (+10/-1)
src/maasserver/node_constraint_filter_forms.py (+79/-0)
src/maasserver/tests/test_api_nodes.py (+18/-0)
src/maasserver/tests/test_node_constraint_filter_forms.py (+77/-0)
Changed in maas: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in maas: | |
assignee: | nobody → Jeroen T. Vermeulen (jtv) |
status: | Triaged → In Progress |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in maas: | |
milestone: | none → 1.6.0 |
Changed in maas: | |
status: | Fix Committed → Fix Released |
I don't see what maas is doing wrong really, the requesting API client really ought to be more helpful since it knows the constraints it was using. In this case Juju should be reporting better errors to its users.
I'll leave this as a wishlist bug in case anyone feels like changing what's logged by MAAS, but given this is an API request the onus is on the API client to inform its users as we should not be expecting them to go diving through MAAS logs to see why a node is not allocated to them.