Re: defaults paths #2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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,
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[CEPH Users]     [Information on CEPH]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux