tht and puppet-ceph improperly/unnecessarily attempts to deploy a client.bootstrap-osd auth entry for cephx enabled ceph clusters.
This results in two problems:
1) a race condition between puppet-ceph creating client.bootstrap-osd files on all nodes and ceph copying the keyring file between the monitor nodes.
2) tht and puppet-ceph changing the ceph generated secret of the keyring.
Here is a description of the race condition events:
1) monitor-1 executes ceph-key-client.bootstrap-osd
to create a new keyring on the local file system
2) monitor-2 executes ceph-key-client.bootstrap-osd
to create a new keyring on the local file system
3) monitor-2 executes ceph-inject-key-client.bootstrap-osd
to add the client key and caps to the ceph auth list
4) ceph will distribute the client.bootstrap-osd keyring to
the other monitors. This will overwrite the keyring written
in #1 with just the client name and cephx secret.
5) monitor-1 executes ceph-injectkey-client.bootstrap-osd. The
diff statement in the unless check will fail because the two
keyrings will not return 0 because the one in $keyring_path will
not contain any caps. The exec will fail with an "Error EINVAL:
auth import: no caps supplied" error because the keyring file
only has the client name and the cephx secret.
Steps to reproduce:
Both are timing dependent and may require multiple re-deployments to cause an expectant outcome.
The race condition will fail with the Error EINVAL: auth import: no caps supplied" error. The nature of the race condition makes it difficult to reproduce.
The secret overwrite will be seen when the diff in the unless statement of ceph::key::ceph-injectkey-${name} fails due to the secrets changing. This is a symptom of the design problem.
This fix will need to be backported to Ocata.
Fix proposed to branch: master /review. openstack. org/566701
Review: https:/