juju 2.0-beta9.1: juju relation status PROVIDES and CONSUMES confused

[Martin Hilton]

The PROVIDES and CONSUMES columns in juju status don't match up to which end of the relation the application corresponds. It looks to be that they are in alphabetical order.

For example:

MODEL CONTROLLER CLOUD VERSION
default canonistack-lcy02-1 canonistack 2.0-beta9.1

APP STATUS EXPOSED ORIGIN CHARM REV OS
apache2 unknown false jujucharms apache2 20 ubuntu
mysql unknown false jujucharms mysql 55 ubuntu
wordpress unknown false jujucharms wordpress 4 ubuntu

RELATION PROVIDES CONSUMES TYPE
website apache2 wordpress regular
cluster mysql mysql peer
db mysql wordpress regular
loadbalancer wordpress wordpress peer

UNIT WORKLOAD AGENT MACHINE PORTS PUBLIC-ADDRESS MESSAGE
apache2/0 unknown allocating 1 10.55.32.101 Waiting for agent initialization to finish
mysql/0 unknown allocating 2 10.55.32.201 Waiting for agent initialization to finish
wordpress/0 unknown allocating 0 10.55.32.187 Waiting for agent initialization to finish

MACHINE STATE DNS INS-ID SERIES AZ
0 pending 10.55.32.187 72ce5b97-b835-4180-897d-05a5afbbe416 trusty nova
1 pending 10.55.32.101 2eac145d-4a7d-4410-ba58-714346fcc4d2 trusty nova
2 pending 10.55.32.201 6b41bd99-fc70-4328-bd68-e645d0aa5e59 trusty nova

The website relation should be provided by wordpress and consumed by apache2

[Roger Peppe (rogpeppe)]

FWIW the grammatically correct column titles should be "PROVIDER" and "CONSUMER" (or "REQUIRER"
to be consistent with the charm metadata.yaml names).

[Cheryl Jennings (cherylj)]

In the apache2 charm in the charmstore, I see that it is the provider of the website relation:

From: https://api.jujucharms.com/charmstore/v5/trusty/apache2/archive/metadata.yaml

provides:
  nrpe-external-master:
    interface: nrpe-external-master
    scope: container
  local-monitors:
    interface: local-monitors
    scope: container
  website:
    interface: http
  logs:
    interface: logs
  apache-website:
    interface: apache-website
    scope: container

Is this the charm you're using?

[Anastasia (anastasia-macmood)]

Roger's deduction: from the status, it looks like Martin was using the apache2, mysql and wordpress charms

[Anastasia (anastasia-macmood)]

Lowering the priority. It would be nice if column headers were aligned with metadata.yaml as per comment # 1.

[Jay R. Wren (evarlast)]

This was very confusing.

Extra confusion because apache2 charm starts with 'a' so always is in PROVIDES column, but in my case, I was replacing apache2 charm with haproxy charm and expected to see haproxy in the PROVIDES column (because that is where it is in the apache2 output, not necessarily because that is the function it provides).

What I got instead:

RELATION PROVIDES CONSUMES TYPE
logs apache2 beaver subordinate
balancer apache2 blues-browser regular
balancer apache2 blues-identity-haproxy regular
balancer apache2 blues-payment regular
balancer apache2 charmstore regular
balancer apache2 jem regular
balancer apache2 juju-gui regular
balancer apache2 kibana regular
balancer apache2 omnibus2-haproxy regular
balancer apache2 prometheus regular
balancer apache2 terms-haproxy regular

RELATION PROVIDES CONSUMES TYPE
reverseproxy blues-browser haproxy regular
reverseproxy blues-identity-haproxy haproxy regular
reverseproxy blues-payment haproxy regular
reverseproxy charmstore haproxy regular
peer haproxy haproxy peer
reverseproxy haproxy jem regular
reverseproxy haproxy kibana regular
reverseproxy haproxy omnibus2-haproxy regular
reverseproxy haproxy prometheus regular
reverseproxy haproxy terms-haproxy regular

even though each relation was added with `haproxy:reverseproxy` specified.

Is juju doing the right thing with the relations and it is only a juju status output bug? Is juju doing the wrong thing with relations based on the names of things related?

[Christian Muirhead (2-xtian)]

Fixed in https://github.com/juju/juju/pull/7729

Juju was handling the relations right, but it was displaying them in a nonsensical way in the tabular status output. Now we display them like:

Relation provider Requirer Interface Type
prometheus:website haproxy:reverseproxy http regular