juju status not showing correct output when specifying a specific service/application

Bug #1592872 reported by Jeff Hillman
42
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Fix Released
Medium
Anastasia
2.3
Fix Released
Medium
Anastasia

Bug Description

juju 2.0 beta8

When running juju status against a specific service/application (nova-compute for example) the output of the command is very inconsistent.

Here are some examples:

ubuntu@maas:~$ juju status nova-compute
[Services]
NAME STATUS EXPOSED CHARM
ceph-osd blocked false cs:xenial/ceph-osd-2
nova-compute blocked false cs:xenial/nova-compute-1

[Relations]
SERVICE1 SERVICE2 RELATION TYPE
nova-compute nova-compute compute-peer peer

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
ceph-osd/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relation: monitor
ceph-osd/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relation: monitor
ceph-osd/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relation: monitor
ceph-osd/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relation: monitor
ceph-osd/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relation: monitor
nova-compute/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: messaging, image
nova-compute/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relations: messaging, image
nova-compute/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relations: messaging, image
nova-compute/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relations: messaging, image
nova-compute/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relations: messaging, image

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 192.168.100.12 4y3h7q xenial default
1 started 192.168.100.13 4y3h7r xenial default
2 started 192.168.100.14 4y3h7s xenial default
3 started 192.168.100.15 4y3h7t xenial default
4 started 192.168.100.11 4y3h7p xenial default

ubuntu@maas:~$ juju status nova-compute
[Services]
NAME STATUS EXPOSED CHARM
ceph-osd blocked false cs:xenial/ceph-osd-2
neutron-api blocked false cs:xenial/neutron-api-1
neutron-gateway blocked false cs:xenial/neutron-gateway-1
nova-compute blocked false cs:xenial/nova-compute-1
swift-storage blocked false cs:xenial/swift-storage-2

[Relations]
SERVICE1 SERVICE2 RELATION TYPE
neutron-api neutron-api cluster peer
neutron-gateway neutron-gateway cluster peer
nova-compute nova-compute compute-peer peer

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
ceph-osd/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relation: monitor
ceph-osd/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relation: monitor
ceph-osd/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relation: monitor
ceph-osd/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relation: monitor
ceph-osd/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relation: monitor
neutron-api/0 blocked idle 2.0-beta8 0 9696/tcp 192.168.100.12 Missing relations: messaging, identity, database
neutron-gateway/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: messaging
nova-compute/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: messaging, image
nova-compute/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relations: messaging, image
nova-compute/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relations: messaging, image
nova-compute/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relations: messaging, image
nova-compute/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relations: messaging, image
swift-storage/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: proxy
swift-storage/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relations: proxy
swift-storage/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relations: proxy
swift-storage/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relations: proxy
swift-storage/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relations: proxy

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 192.168.100.12 4y3h7q xenial default
1 started 192.168.100.13 4y3h7r xenial default
2 started 192.168.100.14 4y3h7s xenial default
3 started 192.168.100.15 4y3h7t xenial default
4 started 192.168.100.11 4y3h7p xenial default

ubuntu@maas:~$ juju status nova-compute
[Services]
NAME STATUS EXPOSED CHARM
ceph-osd blocked false cs:xenial/ceph-osd-2
neutron-gateway blocked false cs:xenial/neutron-gateway-1
nova-compute blocked false cs:xenial/nova-compute-1
swift-storage blocked false cs:xenial/swift-storage-2

[Relations]
SERVICE1 SERVICE2 RELATION TYPE
neutron-gateway neutron-gateway cluster peer
nova-compute nova-compute compute-peer peer

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE
ceph-osd/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relation: monitor
ceph-osd/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relation: monitor
ceph-osd/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relation: monitor
ceph-osd/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relation: monitor
ceph-osd/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relation: monitor
neutron-gateway/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: messaging
nova-compute/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: messaging, image
nova-compute/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relations: messaging, image
nova-compute/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relations: messaging, image
nova-compute/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relations: messaging, image
nova-compute/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relations: messaging, image
swift-storage/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: proxy
swift-storage/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relations: proxy
swift-storage/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relations: proxy
swift-storage/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relations: proxy
swift-storage/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relations: proxy

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 192.168.100.12 4y3h7q xenial default
1 started 192.168.100.13 4y3h7r xenial default
2 started 192.168.100.14 4y3h7s xenial default
3 started 192.168.100.15 4y3h7t xenial default
4 started 192.168.100.11 4y3h7p xenial default

expected output would be:

ubuntu@maas:~$ juju status nova-compute
[Services]
NAME STATUS EXPOSED CHARM
nova-compute blocked false cs:xenial/nova-compute-1

[Relations]
SERVICE1 SERVICE2 RELATION TYPE
nova-compute nova-compute compute-peer peer

[Units]
ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS PUBLIC-ADDRESS MESSAGE

nova-compute/0 blocked idle 2.0-beta8 0 192.168.100.12 Missing relations: messaging, image
nova-compute/1 blocked idle 2.0-beta8 1 192.168.100.13 Missing relations: messaging, image
nova-compute/2 blocked idle 2.0-beta8 2 192.168.100.14 Missing relations: messaging, image
nova-compute/3 blocked idle 2.0-beta8 3 192.168.100.15 Missing relations: messaging, image
nova-compute/4 blocked idle 2.0-beta8 4 192.168.100.11 Missing relations: messaging, image

[Machines]
ID STATE DNS INS-ID SERIES AZ
0 started 192.168.100.12 4y3h7q xenial default
1 started 192.168.100.13 4y3h7r xenial default
2 started 192.168.100.14 4y3h7s xenial default
3 started 192.168.100.15 4y3h7t xenial default
4 started 192.168.100.11 4y3h7p xenial default

Revision history for this message
Jeff Hillman (jhillman) wrote :

Specifically this can be repeated with juju status nova-compute and juju status keystone, however it doesn't appear to be affecting juju status rabbitmq-server or juju status nova-cloud-controller

summary: - juju status not showing correct output when specifying a sepcific
+ juju status not showing correct output when specifying a specific
service/application
Revision history for this message
Cheryl Jennings (cherylj) wrote :

I haven't been able to reproduce locally. I have a couple questions for you:

1 - Can you reproduce this problem reliably?

2 - Is there a particular bundle you're using when you run into this?

3 - When you see it again, can you also include the full `juju status` and `juju status --format=yaml` output?

Changed in juju-core:
status: New → Incomplete
Revision history for this message
Jeff Hillman (jhillman) wrote : Re: [Bug 1592872] Re: juju status not showing correct output when specifying a specific service/application
Download full text (9.9 KiB)

I'm working right now to build out a new lab. When i get it up I'll let
you know.
On Jun 20, 2016 10:05 AM, "Cheryl Jennings" <email address hidden>
wrote:

> I haven't been able to reproduce locally. I have a couple questions for
> you:
>
> 1 - Can you reproduce this problem reliably?
>
> 2 - Is there a particular bundle you're using when you run into this?
>
> 3 - When you see it again, can you also include the full `juju status`
> and `juju status --format=yaml` output?
>
>
> ** Changed in: juju-core
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1592872
>
> Title:
> juju status not showing correct output when specifying a specific
> service/application
>
> Status in juju-core:
> Incomplete
>
> Bug description:
> juju 2.0 beta8
>
> When running juju status against a specific service/application (nova-
> compute for example) the output of the command is very inconsistent.
>
> Here are some examples:
>
> ubuntu@maas:~$ juju status nova-compute
> [Services]
> NAME STATUS EXPOSED CHARM
> ceph-osd blocked false cs:xenial/ceph-osd-2
> nova-compute blocked false cs:xenial/nova-compute-1
>
> [Relations]
> SERVICE1 SERVICE2 RELATION TYPE
> nova-compute nova-compute compute-peer peer
>
> [Units]
> ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS
> PUBLIC-ADDRESS MESSAGE
> ceph-osd/0 blocked idle 2.0-beta8 0
> 192.168.100.12 Missing relation: monitor
> ceph-osd/1 blocked idle 2.0-beta8 1
> 192.168.100.13 Missing relation: monitor
> ceph-osd/2 blocked idle 2.0-beta8 2
> 192.168.100.14 Missing relation: monitor
> ceph-osd/3 blocked idle 2.0-beta8 3
> 192.168.100.15 Missing relation: monitor
> ceph-osd/4 blocked idle 2.0-beta8 4
> 192.168.100.11 Missing relation: monitor
> nova-compute/0 blocked idle 2.0-beta8 0
> 192.168.100.12 Missing relations: messaging, image
> nova-compute/1 blocked idle 2.0-beta8 1
> 192.168.100.13 Missing relations: messaging, image
> nova-compute/2 blocked idle 2.0-beta8 2
> 192.168.100.14 Missing relations: messaging, image
> nova-compute/3 blocked idle 2.0-beta8 3
> 192.168.100.15 Missing relations: messaging, image
> nova-compute/4 blocked idle 2.0-beta8 4
> 192.168.100.11 Missing relations: messaging, image
>
> [Machines]
> ID STATE DNS INS-ID SERIES AZ
> 0 started 192.168.100.12 4y3h7q xenial default
> 1 started 192.168.100.13 4y3h7r xenial default
> 2 started 192.168.100.14 4y3h7s xenial default
> 3 started 192.168.100.15 4y3h7t xenial default
> 4 started 192.168.100.11 4y3h7p xenial default
>
> ubuntu@maas:~$ juju status nova-compute
> [Services]
> NAME STATUS EXPOSED CHARM
> ceph-osd blocked false cs:xenial/ceph-osd-2
> neutron-api blocked false cs:xenial/neutron-api-1
> neutron-gateway blocked false cs...

Revision history for this message
Jeff Hillman (jhillman) wrote :
Download full text (16.1 KiB)

I finally have my environment up, now running junu-2.0 beta9 and i'm having
the same issue. It mostly happens, so far, when running 'juju status
nova-compute' sometimes it just shows nova-compute and other times it
shows ceph-osd, or neutron-gateway or other random services.

here's juju status --format=yaml nova-compute a couple of times

ubuntu@ubuntu:~$ juju status --format=yaml nova-compute
model: default
machines:
  "0":
    juju-status:
      current: started
      since: 21 Jun 2016 19:32:10-04:00
      version: 2.0-beta7
    dns-name: 172.71.100.2
    instance-id: 4y3h7q
    machine-status:
      current: running
      message: Deployed
      since: 21 Jun 2016 19:31:38-04:00
    series: xenial
    hardware: arch=amd64 cpu-cores=4 mem=8192M availability-zone=default
services:
  ceph-osd:
    charm: cs:xenial/ceph-osd-2
    exposed: false
    service-status:
      current: blocked
      message: 'Missing relation: monitor'
      since: 21 Jun 2016 19:40:11-04:00
    units:
      ceph-osd/0:
        workload-status:
          current: blocked
          message: 'Missing relation: monitor'
          since: 21 Jun 2016 19:40:11-04:00
        juju-status:
          current: idle
          since: 21 Jun 2016 19:40:12-04:00
          version: 2.0-beta7
        machine: "0"
        public-address: 172.71.100.2
  neutron-gateway:
    charm: cs:xenial/neutron-gateway-1
    exposed: false
    service-status:
      current: blocked
      message: 'Missing relations: messaging'
      since: 21 Jun 2016 19:43:33-04:00
    relations:
      cluster:
      - neutron-gateway
    units:
      neutron-gateway/0:
        workload-status:
          current: blocked
          message: 'Missing relations: messaging'
          since: 21 Jun 2016 19:43:33-04:00
        juju-status:
          current: idle
          since: 21 Jun 2016 19:43:33-04:00
          version: 2.0-beta7
        machine: "0"
        public-address: 172.71.100.2
  nova-compute:
    charm: cs:xenial/nova-compute-1
    exposed: false
    service-status:
      current: blocked
      message: 'Missing relations: messaging, image'
      since: 21 Jun 2016 19:39:29-04:00
    relations:
      compute-peer:
      - nova-compute
    units:
      nova-compute/0:
        workload-status:
          current: blocked
          message: 'Missing relations: messaging, image'
          since: 21 Jun 2016 19:39:29-04:00
        juju-status:
          current: idle
          since: 21 Jun 2016 19:39:30-04:00
          version: 2.0-beta7
        machine: "0"
        public-address: 172.71.100.2

ubuntu@ubuntu:~$ juju status --format=yaml nova-compute
model: default
machines:
  "0":
    juju-status:
      current: started
      since: 21 Jun 2016 19:32:10-04:00
      version: 2.0-beta7
    dns-name: 172.71.100.2
    instance-id: 4y3h7q
    machine-status:
      current: running
      message: Deployed
      since: 21 Jun 2016 19:31:38-04:00
    series: xenial
    hardware: arch=amd64 cpu-cores=4 mem=8192M availability-zone=default
services:
  nova-compute:
    charm: cs:xenial/nova-compute-1
    exposed: false
    service-status:
      current: blocked
      message: 'Missing relations: messaging, image'
 ...

Changed in juju-core:
status: Incomplete → Triaged
importance: Undecided → High
affects: juju-core → juju
Changed in juju:
milestone: none → 2.1.0
Revision history for this message
Anastasia (anastasia-macmood) wrote :

Removing 2.1 milestone as we will not be addressing this issue in 2.1.

Changed in juju:
milestone: 2.1.0 → 2.2.0
tags: added: oil
Revision history for this message
Anastasia (anastasia-macmood) wrote :

This information is being displayed because these units/applications are deployed to the same machine as the application you are interested in, concretely 'nova-compute' units are on machines 0, 1, 2, 3, 4 but so are ceph-osd, neutron-gateway, swift-storage. I've extracted relevant details from your report.

As juju status aims to give you an idea of all relevant information with respect to your query, it considered that you wanted to know what else is going on with the machines that your application units are deployed to. Hence, you got the details of other applications.

ID MACHINE
ceph-osd/0 0
ceph-osd/1 1
ceph-osd/2 2
ceph-osd/3 3
ceph-osd/4 4
neutron-gateway/0 0
nova-compute/0 0
nova-compute/1 1
nova-compute/2 2
nova-compute/3 3
nova-compute/4 4
swift-storage/0 0
swift-storage/1 1
swift-storage/2 2
swift-storage/3 3
swift-storage/4 4

Changed in juju:
status: Triaged → Incomplete
milestone: 2.2.0 → none
status: Incomplete → Invalid
importance: High → Undecided
Revision history for this message
Jeff Hillman (jhillman) wrote :
Download full text (10.7 KiB)

Correct assesment. However, regardless of intent, the behavior is not
consistent. It doesn't always show the same thing.

On Feb 20, 2017 8:49 PM, "Anastasia" <email address hidden>
wrote:

> This information is being displayed because these units/applications are
> deployed to the same machine as the application you are interested in,
> concretely 'nova-compute' units are on machines 0, 1, 2, 3, 4 but so are
> ceph-osd, neutron-gateway, swift-storage. I've extracted relevant
> details from your report.
>
> As juju status aims to give you an idea of all relevant information with
> respect to your query, it considered that you wanted to know what else
> is going on with the machines that your application units are deployed
> to. Hence, you got the details of other applications.
>
> ID MACHINE
> ceph-osd/0 0
> ceph-osd/1 1
> ceph-osd/2 2
> ceph-osd/3 3
> ceph-osd/4 4
> neutron-gateway/0 0
> nova-compute/0 0
> nova-compute/1 1
> nova-compute/2 2
> nova-compute/3 3
> nova-compute/4 4
> swift-storage/0 0
> swift-storage/1 1
> swift-storage/2 2
> swift-storage/3 3
> swift-storage/4 4
>
>
>
> ** Changed in: juju
> Status: Triaged => Incomplete
>
> ** Changed in: juju
> Milestone: 2.2.0 => None
>
> ** Changed in: juju
> Status: Incomplete => Invalid
>
> ** Changed in: juju
> Importance: High => Undecided
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1592872
>
> Title:
> juju status not showing correct output when specifying a specific
> service/application
>
> Status in juju:
> Invalid
>
> Bug description:
> juju 2.0 beta8
>
> When running juju status against a specific service/application (nova-
> compute for example) the output of the command is very inconsistent.
>
> Here are some examples:
>
> ubuntu@maas:~$ juju status nova-compute
> [Services]
> NAME STATUS EXPOSED CHARM
> ceph-osd blocked false cs:xenial/ceph-osd-2
> nova-compute blocked false cs:xenial/nova-compute-1
>
> [Relations]
> SERVICE1 SERVICE2 RELATION TYPE
> nova-compute nova-compute compute-peer peer
>
> [Units]
> ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS
> PUBLIC-ADDRESS MESSAGE
> ceph-osd/0 blocked idle 2.0-beta8 0
> 192.168.100.12 Missing relation: monitor
> ceph-osd/1 blocked idle 2.0-beta8 1
> 192.168.100.13 Missing relation: monitor
> ceph-osd/2 blocked idle 2.0-beta8 2
> 192.168.100.14 Missing relation: monitor
> ceph-osd/3 blocked idle 2.0-beta8 3
> 192.168.100.15 Missing relation: monitor
> ceph-osd/4 blocked idle 2.0-beta8 4
> 192.168.100.11 Missing relation: monitor
> nova-compute/0 blocked idle 2.0-beta8 0
> 192.168.100.12 Missing relations: messaging, image
> nova-compute/1 blocked idle 2.0-beta8 1
> 192.168.100.13 Missing relations: messaging, image
> nova-compute/2 blocked idle 2.0-beta8 2
> 192.168.100.14 Missing relations: messaging, image
> nova-compute/3 blocked idle 2...

Revision history for this message
Anastasia (anastasia-macmood) wrote :

The behavior, in this instance, depends on what is going on behind the scenes.
As different units come up, status will have different output. If you were to deploy other units to the same machines or remove existing units, the output will change.

Revision history for this message
Jason Hobbs (jason-hobbs) wrote :

The output varies long after the services have deployed and are in steady state.

Changed in juju:
status: Invalid → New
tags: added: usability
Changed in juju:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Fairbanks. (fairbanks) wrote :

Hello, i have the same thing.
When using `watch` to keep track of the changes it changes the layout a lot.
I have this with cinder for instances, and it sometimes showing me the neutron-gateway unit on that same machine also. Even when there is nothing changed on that unit.

Using the openstack bundle btw.

Revision history for this message
John A Meinel (jameinel) wrote :

I believe the logic is probably consistent, if unexpected. I believe what actually happens when you type "juju status foo" is that we find applications named foo, find the units of the application, then find the machines where those units are running, and then display all of the information about those machines (including other applications that are running on those machines).

The reason 'juju status rabbitmq-server' isn't showing you extra information is probably because you don't have other applications running colocated with rabbitmq-server.

Looking at the initial output, all of those units were on machines 0,1,2,3,4.

The other thing to consider is applications deployed into containers next to the applications that are on the host machine. I *think* we probably include those as well. (Certainly juju show-machine 0/juju status --format=yaml 0 show you the details of containers on that machine.)

I haven't dug into each message in this thread to see if that is true.

That said, I think a more expected output is that restricting by application might show you the machine that the unit is running on, but would filter out any other applications running on that machine.

Revision history for this message
Jason Hobbs (jason-hobbs) wrote :
Download full text (10.8 KiB)

John,

That does not explain why the output of juju status <application> for the
same application would, from run to run, show a different set of services.

On Wed, Apr 12, 2017 at 6:08 AM, John A Meinel <email address hidden>
wrote:

> I believe the logic is probably consistent, if unexpected. I believe
> what actually happens when you type "juju status foo" is that we find
> applications named foo, find the units of the application, then find the
> machines where those units are running, and then display all of the
> information about those machines (including other applications that are
> running on those machines).
>
> The reason 'juju status rabbitmq-server' isn't showing you extra
> information is probably because you don't have other applications
> running colocated with rabbitmq-server.
>
> Looking at the initial output, all of those units were on machines
> 0,1,2,3,4.
>
> The other thing to consider is applications deployed into containers
> next to the applications that are on the host machine. I *think* we
> probably include those as well. (Certainly juju show-machine 0/juju
> status --format=yaml 0 show you the details of containers on that
> machine.)
>
> I haven't dug into each message in this thread to see if that is true.
>
> That said, I think a more expected output is that restricting by
> application might show you the machine that the unit is running on, but
> would filter out any other applications running on that machine.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1661407).
> https://bugs.launchpad.net/bugs/1592872
>
> Title:
> juju status not showing correct output when specifying a specific
> service/application
>
> Status in juju:
> Triaged
>
> Bug description:
> juju 2.0 beta8
>
> When running juju status against a specific service/application (nova-
> compute for example) the output of the command is very inconsistent.
>
> Here are some examples:
>
> ubuntu@maas:~$ juju status nova-compute
> [Services]
> NAME STATUS EXPOSED CHARM
> ceph-osd blocked false cs:xenial/ceph-osd-2
> nova-compute blocked false cs:xenial/nova-compute-1
>
> [Relations]
> SERVICE1 SERVICE2 RELATION TYPE
> nova-compute nova-compute compute-peer peer
>
> [Units]
> ID WORKLOAD-STATUS JUJU-STATUS VERSION MACHINE PORTS
> PUBLIC-ADDRESS MESSAGE
> ceph-osd/0 blocked idle 2.0-beta8 0
> 192.168.100.12 Missing relation: monitor
> ceph-osd/1 blocked idle 2.0-beta8 1
> 192.168.100.13 Missing relation: monitor
> ceph-osd/2 blocked idle 2.0-beta8 2
> 192.168.100.14 Missing relation: monitor
> ceph-osd/3 blocked idle 2.0-beta8 3
> 192.168.100.15 Missing relation: monitor
> ceph-osd/4 blocked idle 2.0-beta8 4
> 192.168.100.11 Missing relation: monitor
> nova-compute/0 blocked idle 2.0-beta8 0
> 192.168.100.12 Missing relations: messaging, image
> nova-compute/1 blocked idle 2.0-beta8 1
> 192.168.100.13 Missing relations: messaging, image
> nova-compute/2 blocked idle ...

Alvaro Uria (aluria)
tags: added: canonical-bootstack
Changed in juju:
status: Triaged → In Progress
assignee: nobody → Anastasia (anastasia-macmood)
Revision history for this message
Anastasia (anastasia-macmood) wrote :

I have written a simple and I can reproduce inconsistent behavior.

My test is not at presentation layer but at the apiserver (business logic). I am adding 3 applications such that:

* application 1 uses 'mysql' charm; is named "abc"; has a unit on machine 0;

* application 2 uses 'wordpress' charm; is named "def"; has a unit on machine 0; has a relation to application 3;

* application 3 uses 'logging' charm; is named "klm"; has a relation to application 2.

In my test, I am only interested in applications returned from our status call.

When I filter on application 1 name, i.e. "abc", I get 2 applications returned consistently - 'abc' and 'def' - as expected. Their order in the result is inconsistent, but I do get 2 applications. Always.

When I filter status on either "abc" or "def", i.e. expecting 2 applications in the result, I get inconsistently either 1 or 2, even on a stable system.

I am still investigating the cause.

Revision history for this message
Anastasia (anastasia-macmood) wrote :

It looks like there is an ordering bug.

When determining if a unit matches the filter "abc", if we get a collection of units keyed on [def, abc], we will consistently not get a 'def' in the result. However, if the keys are [abc, def], then we'd get both applications in the result.

It looks like to be consistent, we need another pass through - once we've collected all units that match the filter, get everything related to their machines...

Revision history for this message
Anastasia (anastasia-macmood) wrote :
Changed in juju:
milestone: none → 2.4-beta3
Revision history for this message
Anastasia (anastasia-macmood) wrote :
Changed in juju:
status: In Progress → Fix Committed
Changed in juju:
status: Fix Committed → Fix Released
Revision history for this message
Jeff Hillman (jhillman) wrote :

This behavior still happens in juju 2.9.32

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

It's likely to be a different root cause with similar symptoms. Can you raise a new bug with example output to help diagnose the issue? A new bug can be triaged appropriately.

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.