Comment 1 for bug 1696245

I think we're running into a little bit of 'DWIM' issues. For example if
you do "juju status error" and nothing is in error, would you expect it to
give you a nonzero exit?
Is it only machine numbers that should exit nonzero?
What about application names that are typo'd?
What about unit numbers? app/10
I'm curious how
  'juju status 123' doesn't return an empty list but 'juju status 1234' is
empty. Do you have a machine 123?

It feels like we need to be less DWIM before we can really know for sure
what the user intended, and cause an error if we can't satisfy that request.

John
=:->

On Wed, Jun 7, 2017 at 12:42 AM, Richard Harding <<email address hidden>
> wrote:

> Public bug reported:
>
> I've bootstrapped a controller with 2.2-rc1. There are only the default
> models of controller and default. I've deployed several applications
> into the controller model. I can run juju status on that model and get a
> normal looking status.
>
> If I run:
>
> juju status 123
>
> I actually get the status output of the controller model which is the
> current one selected.
>
> If I run:
>
> juju status 1234
>
> I get status for the controller, but everything is empty. It looks like
> the status of a completely empty model. No machines or applications
> deployed.
>
> If I run:
>
> juju status -m 1234
>
> I get an expected
>
> ERROR model test:admin/1234 not found
>
> I think that the status by application/unit should also error if the
> application or unit name are not matched vs random status output that
> appears to come out currently.
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1696245
>
> Title:
> juju status does not fail obviously when bad input it used
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1696245/+subscriptions
>