The ceph-mon charm uses the mon api to coordinate upgrades (using it to get/set keys that represent upgrade state). There is a know issue in Ceph where older clients sometimes have problems reaching mons that have been upgraded and when this happens it prevents the charm from progressing with the upgrade. This is a problem because if the charm just went ahead and installed the new client it would not have this problem and the part of an upgrade that really requires coordination - the restarting of mon daemons - would be allowed to continue.
An example is the following, where 2/3 mon units are already running Nautilus and the remaining unit is still running Mimic. When the Mimic unit tries to reach the mon api to read its keys it gets:
root@juju-985145-sf00292484-test-2:~# ceph -s
Traceback (most recent call last):
File "/usr/bin/ceph", line 1241, in <module>
retval = main()
File "/usr/bin/ceph", line 1165, in main
sigdict = parse_json_funcsigs(outbuf.decode('utf-8'), 'cli')
File "/usr/lib/python3/dist-packages/ceph_argparse.py", line 788, in parse_json_funcsigs
cmd['sig'] = parse_funcsig(cmd['sig'])
File "/usr/lib/python3/dist-packages/ceph_argparse.py", line 728, in parse_funcsig
raise JsonFormat(s)
ceph_argparse.JsonFormat: unknown type CephBool
To fix this we manually upgrade the client to Nautilus and that allowed the charm to proceed. So, one solution to this would be have the charm install the new apt source and upgrade packages in an uncoordinated way i.e. just do it and then use its existed rolling upgrade mechanism to coordinate mon daemon restarts.
Fix proposed to branch: master
Review: https:/