Description of problem:
Presently, TripleO is not capable of deploying a Ceph cluster with a name different than the default "ceph". In order to work properly with RBD mirroring, we need to have the ability to deploy Ceph clusters with a dedicated name. In a DR scenario, we might have a "primary" cluster and a "secondary" cluster on the DR site.
puppet-ceph is already capable of doing this, so we only need to expose this capability up to TripleO.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Note: the rbd-mirror daemon really does *not* require different cluster names. It only requires two "ceph.conf" configuration files to talk to the local and remote cluster. Therefore, you could just as easily copy remote cluster's ceph.conf to "remote.conf" and just use "remote" as the name of the remote ceph cluster -- since the cluster name is actually only used for locating the configuration file.
Right, I should have marked this as optional, I just believe that from an operational perspective it might be valuable to have this. Especially in the context of multisite.
What about keys though? I guess we need to change the path of the admin key (if we want to use this one) in the ceph.conf, right?
In a perfect world, it would be great if ceph-ansible would create a new user for rbd-mirror so that it didn't use the admin keyring (with full permissions for everything for both the local and remote clusters).
You are correct that you would want to update the keyring within the copied remote ceph.conf (or preferably blank it out so that it locates it automatically by cluster and user name ).
Depending on the outcome yes, the situation is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1459861
Alright, it seems that it has been confirmed here https://bugzilla.redhat.com/show_bug.cgi?id=1459861, we don't want to expose cluster names in the next ceph-ansible release. This release will be used by OSP12, thus we can abandon this.
Instead, we need a right documentation to configure mirroring. This is mainly a post-deployment task.
I'm not closing this, we can potentially track the doc here but we can stop the development.
I guess this is going to need a few changes in the puppet modules too, we'll probably work it with multiple submissions from different people.
*** Bug 1429605 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.