interface: juju-info gets no love in the GUI

[chuckbutler]

So the juju-info relationship is a pretty touchy subject, as charms shouldn't be using it... unless you're a subordinate.

When deploying subordinate services that make use of 'interface:juju-info' for that special "deploy and relate to anything subordinate" - it gets zero love in the Juju GUI these days

for example, deploy the beats-core service

juju deploy ~containers/development/bundle/beats-core

and attempt to relate any of the *beat services to a unit for monitoring. The relation arm greys out the entire topology leaving it appearing that it has no services it can possibly communicate with.

However, in the cli if you juju add-relation filebeat:beats-host kibana, it will relate just fine.

[frankban]

This one seems to be fixed in current develop.
So here is what I did on a AWS model:

• juju deploy cs:bundle/beats-core-0;
• juju upgrade-gui /path/to/jujugui-2.1.13.tar.bz2;
• juju gui;
• then, using the GUI, I was able to relate both filebeat and tobbeat to kibana;
  At the end of the process above, here is the Juju status:

MODEL    CONTROLLER  CLOUD/REGION      VERSION
default  aws         aws/eu-central-1  2.0-rc2.1

APP            VERSION  STATUS   SCALE  CHARM          STORE       REV  OS      NOTES
elasticsearch           unknown      1  elasticsearch  jujucharms   15  ubuntu  
filebeat                active       1  filebeat       jujucharms    2  ubuntu  
kibana                  active       1  kibana         jujucharms   12  ubuntu  exposed
topbeat                 active       1  topbeat        jujucharms    2  ubuntu  

UNIT             WORKLOAD  AGENT  MACHINE  PUBLIC-ADDRESS  PORTS            MESSAGE
elasticsearch/0  unknown   idle   0        52.57.6.112     9200/tcp         
kibana/0         active    idle   1        52.57.140.64    80/tcp,9200/tcp  ready
  filebeat/0     active    idle            52.57.140.64                     Filebeat ready
  topbeat/0      active    idle            52.57.140.64                     Topbeat ready

MACHINE  STATE    DNS           INS-ID      SERIES  AZ
0        started  52.57.6.112   i-44a283f8  trusty  eu-central-1b
1        started  52.57.140.64  i-8281153f  trusty  eu-central-1a

RELATION       PROVIDES       CONSUMES       TYPE
peer           elasticsearch  elasticsearch  peer
elasticsearch  elasticsearch  filebeat       regular
rest           elasticsearch  kibana         regular
elasticsearch  elasticsearch  topbeat        regular
juju-info      filebeat       kibana         regular
beats-host     kibana         filebeat       subordinate
beats-host     kibana         topbeat        subordinate

After a quick look at the code, it doesn't seem to me that there is anything preventing subordinate charms to connect to remote juju-info endpoints. Is there anything I am missing?

[hatched]

Thanks a lot for this investigation @frankban this is great that this works.

Do you know if it gives you an explicit option to create a juju-info relation when creating the relation is ambiguous?

[frankban]

This has been fixed, confirmed again.