Juju 2 status doesn't show error reason in default format

Bug #1575283 reported by Jeff Pihach
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Fix Released
Medium
Unassigned

Bug Description

I had machine allocation errors when trying to deploy a bundle but juju status for the machines just showed 'error'

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 54.198.158.54 i-f4ada56f trusty us-east-1a
1 started 54.147.228.227 i-b559ce28 trusty us-east-1c
2 error pending trusty
3 error pending trusty
4 error pending trusty
5 error pending trusty
6 error pending trusty
7 error pending trusty

I had to run `juju status --format=yaml` to get the real error.

  "5":
    juju-status:
      current: error
      message: 'cannot run instances: The specified instance type can only be used
        in a VPC. A subnet ID or network interface ID is required to carry out the
        request. (VPCResourceNotSpecified)'
      since: 26 Apr 2016 10:54:12-06:00
    instance-id: pending
    machine-status:
      current: pending
      since: 26 Apr 2016 10:54:03-06:00
    series: trusty

The default status should output the error messages because I don't feel that a typical user will think to change the status format to get more information.

Changed in juju-core:
status: New → Triaged
importance: Undecided → Medium
tags: added: juju-release-support status usability
Revision history for this message
Jay R. Wren (evarlast) wrote :
Revision history for this message
Eric Snow (ericsnowcurrently) wrote :

FYI, I've opened lp:1575310 as a feature request for a more obvious "juju status --verbose".

Revision history for this message
Ian Booth (wallyworld) wrote :

This is a deliberate decision - tabular status is supposed to be concise to make everything fit nicely on a screen and hence be readable. By the time relations, services, networks, storage etc are added, that's a lot of information to fit in, and each entry is supposed to occupy one line.
It does show there's an error. I think the best option is to show more verbose error information when the user filters the output to errored entities only using "juju status error"

Revision history for this message
Jeff Pihach (hatch) wrote :

Even if we assume that the typical user will run `juju help status` when they get an error (which I think is unlikely) to figure out that there may be a way to get more detailed information, there is no indication that the various status formats include different types of data in this help output.

I believe that every time there is an instance where something goes wrong the tools should provide clear and concise information to the user on how they can go about determining what the issue is and how to resolve it. If you're going to truncate data in the default output then at least a command should be displayed instructing the user on how to get more detailed information.

Revision history for this message
Cheryl Jennings (cherylj) wrote :

We could have the status command be smart enough when a machine is in 'error' to tack on a message about using --format=yaml (or --verbose, as bug #1575310 requests)

Changed in juju-core:
milestone: none → 2.0.0
affects: juju-core → juju
Changed in juju:
milestone: 2.0.0 → none
milestone: none → 2.0.0
Curtis Hovey (sinzui)
Changed in juju:
milestone: 2.0.0 → 2.0.1
Curtis Hovey (sinzui)
Changed in juju:
milestone: 2.0.1 → none
Revision history for this message
Anastasia (anastasia-macmood) wrote :

We have had a lot of discussion around surfacing errors in status.

Current consensus is that if 'status --format=yaml' does not suit your needs, you could use a status filter to display only error states, "juju status error".

Changed in juju:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.