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. Basically, there's two ways of using Ceph. One is "do what ever you want", the other one is "managed". Managed needs to really know what goes where. If you want managed mode to always enforce configuration to contain osd data, osd journal, mon data, just to be safe, and for it to break the very first moment a sysadmin edits the config file, we can do that. But there's no way the managed mode is going to be able to be fully featured if file locations are completely based on the configuration file. I'd rather not have too many "must be here" items in the config file, to tempt the admin into editing it. Nothing will ever prevent the "do what ever you want" side, but I'd like the defaults to fit the "managed" mode. Think of it this way: ceph.conf with arbitrary contents is a one way mapping. I expect to need a two-way mapping. Or, I can just make managed mode *always* pass in explicit --osd-data etc. Then ceph.conf won't matter. I wouldn't describe that as simpler, though. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html