Ceph-admin relation oddities

Concerning the ceph-admin interface, we are experiencing some interesting behavior.

We have created a simple ceph-admin charm here

Our ceph-admin charm relates to the ceph-mon charm to get the fsid, key, and mon_hosts.

The issue we are experiencing is such that the relation data is all set to none on the initial relation, we have to unrelate and make a second add-relation to get data to actually show up in our requires side of things. See below.

After 1st juju add-relation ceph-admin:ceph-admin ceph-mon:admin

$ sudo cat /etc/ceph/ceph.conf 
[global]
auth cluster required = cephx
auth service required = cephx
auth client required = cephx

keyring = /etc/ceph/$cluster.$name.keyring
mon host = None
fsid = None

(Now we run juju remove-relation ceph-admin:ceph-admin ceph-mon:admin and re-add the relation with juju add-relation ceph-admin:ceph-admin ceph-mon:admin)

ubuntu@ip-172-31-38-81:~$ sudo cat /etc/ceph/ceph.conf 
[global]
auth cluster required = cephx
auth service required = cephx
auth client required = cephx

keyring = /etc/ceph/$cluster.$name.keyring
mon host = 172.31.102.40:6789 172.31.104.15:6789 172.31.104.163:6789
fsid = 4f943010-3aac-11e9-89c5-0aeab1a19b3c

As you can see the variables only have actual values on the second time we relate the two charms, the first go around the are all None.

This seems impossible as the interface only sets the available flag if all(data.values()), so I’m a little confused here. Possibly this has something to do with conversation vs endpoints?

We are gating on the ceph-admin.available flag set by the ceph-admin interface here

A little baffled at why we only get data the second time we add the relation.

Thoughts?

1 Like

Hey @jamesbeedy,

It looks like that ceph-admin interface was a bit of a toy that was never made available as a general purpose, usable interface but more of a first touch.

I think that it would be worth revisiting as a new interface if it’s needed rather than trusting an unmaintained interface.

1 Like