On Fri, 6 Apr 2012, Tommi Virtanen wrote: > On Thu, Apr 5, 2012 at 22:12, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > Here's what I'm thinking: > > > > - No data paths are hard-coded except for /etc/ceph/*.conf > > - We initially mount osd volumes in some temporary location (say, > > /var/lib/ceph/temp/$uuid) > > - We identify the oid, cluster uuid, etc., and determine where to mount > > it with > > > > ceph-osd --cluster $cluster -i $id --show-config-value osd_data > > > > This will normally give you the default, unless the conf file specified > > something else. > > - Normal people get a default of /var/lib/ceph/$type/$id > > - Multicluster crazies put > > > > [global] > > osd data = /var/lib/ceph/$type/$cluster-$id > > osd journal = /var/lib/ceph/$type/$cluster-$id/journal > > mon data = /var/lib/ceph/$type/$cluster-$id > > > > (or whatever) in /etc/ceph/$cluster.conf and get something else. > > > > Code paths are identical, data flow is identical. We get a simple general > > case, without closing the door on multicluster configurations, which vary > > only by the config value that is easily adjusted on a per-cluster basis... > > Except we lost features. Now I can't iterate the contents of a > directory and know what they mean. I think we'll need that. Unless you infer it from the conf value or some such kludge, but that would be fragile. Okay. I'm good with /var/lib/ceph/$type/$cluster-$id then. Hopefully we can keep things as general as possible, so that brave souls can go out of bounds without getting bitten. For example, never parse the directory name if the same information can be had from the directory contents. Bernard, I suspect it would be pretty simple to make ceph-osd start up either via -i <id> or --uuid <uuid> which would enable a uuid-based scheme like you describe. For these cookbooks, though, it'll be an <id>-based approach. sage
