'juju status MACHINE" fails if any unit is not assigned to a machine

[John A Meinel]

If you manage to mess up deploying a unit (say targeting a machine that doesn't exist yet), you can break 'juju status FILTER'.

Steps to reproduce:

 juju bootstrap
 juju deploy cs:~jameinel/ubuntu-lite ul
 juju add-unit ul --to 2 # no such machine

At this point, 'juju status' will show you something like:
ul/11 waiting allocating waiting for machine
However, trying to get information about an unrelated machine:
 juju status 0
ERROR could not filter units: could not filter units: unit "ul/11" has no assigned machine: unit "ul/11" is not assigned to a machine (not assigned)

Oddly enough, if a machine isn't in the list:
$ juju status waiting
Model Controller Cloud/Region Version SLA
model-1 lxd lxd 2.2-beta3.1 unsupported

App Version Status Scale Charm Store Rev OS Notes
ul waiting 0/1 ubuntu-lite jujucharms 6 ubuntu

Unit Workload Agent Machine Public address Ports Message
ul/11 waiting allocating waiting for machine

Machine State DNS Inst id Series AZ Message

I think its perfectly valid for a unit that is not assigned to a machine to just be omitted if you are filtering wrt a machine (it isn't on *that* machine, is it). It certainly shouldn't prevent seeing other information about the machine you are looking at.

[Anastasia (anastasia-macmood)]

I am not sure how often this scenario occurs in reality :) I had to manipulate state directly to un-assign unit from a machine to properly test the fix.

However, the reason why there was a failure is because one of the checks we run when filtering is whether any of the open ports on a machine for a unit match. Of course, when the unit is not assigned to a machine the check failed saying that we could not figure out unit's machine. I have changed the logic to treat the case of an unassigned unit as a non-match instead of erring out.

This is the fix against 2.3: https://github.com/juju/juju/pull/8744

[John A Meinel (jameinel)]

As mentioned, it was a case of running status in one window, and then doing
"juju add-unit --to X" where X isn't actually a machine in our model. I'm
guessing we are also running into an issue with creating a unit before
verifying its placement directives.
I think we also can hit this if you are deploying a lot (say for testing)
and then run status in another window. I've seen something like this when
doing big deploys and trying to do:
 juju status error

Trying to see if anything comes up broken.

Thanks for the fix

On Wed, May 23, 2018 at 5:57 AM, Anastasia <email address hidden>
wrote:

> I am not sure how often this scenario occurs in reality :) I had to
> manipulate state directly to un-assign unit from a machine to properly
> test the fix.
>
> However, the reason why there was a failure is because one of the checks
> we run when filtering is whether any of the open ports on a machine for
> a unit match. Of course, when the unit is not assigned to a machine the
> check failed saying that we could not figure out unit's machine. I have
> changed the logic to treat the case of an unassigned unit as a non-match
> instead of erring out.
>
> This is the fix against 2.3: https://github.com/juju/juju/pull/8744
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1684718
>
> Title:
> 'juju status MACHINE" fails if any unit is not assigned to a machine
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1684718/+subscriptions
>

[Anastasia (anastasia-macmood)]

PR against develop: https://github.com/juju/juju/pull/8746