Bring back juju wat

[Andrea Ieri]

In juju 1.x it was possible to run `juju wat` to quickly obtain a list of units in error state. I think this was a really useful command, and in fact I have been using an ad-hoc alias to emulate the same functionality.

I think it would be great if `juju wat` made a comeback in some shape or form, either exactly as it used to be, or as a filter to juju status (e.g. `juju status --failed`, which would be identical to how systemd does it).

[Andrea Ieri (aieri)]

FTR I've heard that `wat` was an IS-developed plugin and not part of juju itself.

For reference, the output was as follows (though I'm not suggesting that it should be kept identical):

$ juju wat
ERROR
  nrpe-physical/84
  neutron-api/1
  rabbitmq-server/2 rabbitmq-server/0

[Richard Harding (rharding)]

Thanks, sounds like some other ideas we've had on the roadmap for a long while but not gotten to. I definitely encourage folks to leverage the flexible Juju plugin system to help prototype and share common patterns and tools around Juju.

[Nobuto Murata (nobuto)]

FWIW, juju status syntax is "Usage: juju show-status [options] [filter pattern ...]" and the filter accepts the keyword as "error" or "blocked" to list up all units in each state. It's not clearly documented though.

$ juju status blocked
...

App Version Status Scale Charm Store Rev OS Notes
nova-cloud-controller 17.0.11 blocked 1 nova-cloud-controller jujucharms 339 ubuntu

Unit Workload Agent Machine Public address Ports Message
nova-cloud-controller/0* blocked idle 1 <IP> 8774/tcp,8778/tcp Missing relations: compute, database, image, identity, messaging

Machine State DNS Inst id Series AZ Message
1 started <IP> i-xyz bionic ap-northeast-1d running

[Drew Freiberger (afreiberger)]

I also find it useful to know which charms are still actively running hooks (other than update-status hooks) and use the following list of things to grep out "what juju is working on":

juju status|egrep 'blocked|waiting|maint|error|hook|lost|executing'

This shows everything in juju status that is not an idle, green unit. This is most helpful for determining when charm upgrades are active and complete as well as identifying failed bits. For instance, when updating the keystone charm, just watching keystone's status for blocked or maint doesn't tell you when nova-compute has finished updating all it's relations to keystone unless you query for the "executing" states.

Having this built into juju status CLI would allow for more useful output such as providing the principal unit related to the subordinates that match the filter, etc.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.