Bootstrap cluster not caterred for providing your own ceph.conf about ceph-container

[leseb]

Yes there is preparation step needed when you want to scale your infrastructure.
We assume that ceph.conf, monmap and various keys (admin and bootstraps) will be present on the destination system.
Later when we move to etcd or consul we won't need this as the entry point itself will know how to retrieve those files.

[hookenz]

I think use of etcd or consul should be optional. I don't like the idea of using etcd to hold my keys while the implementation is so open. Same with consul. In my case i provide the keys and config through cloud init and pass them through.

[Ulexus]

Certainly, this would not be to the exclusion of providing your own files.

[hookenz]

Sean, just watched your presentation on CoreOS Fest. Nicely done. Glad I'm not to the only one trying to run this in production. It seems everything I'm trying to run in production is the bleeding edge :)

[Ulexus]

Thanks! Yeah, this is about where I like to stay. Anything else is too boring.

Anyway, I do think the bootstrapping scripts should be a bit more granular, creating things which are needed so that you can supply your own ceph.conf, for instance.

However, this leaves open the possibility that people will expect the ceph.conf to be parsed by the bootstrapping script, too, and I don't really want to go that far. For instance, I do not want to check the ceph.conf, see that an OSD is supposed to run on this server (by hostname? IP?), and then bootstrap it up. Down that road lies madness.

[hookenz]

Agreed. Didn't think if that. I never put osd configs in ceph.conf actually.

I've been looking at ceph-disk activate which won't work with docker unless it's modified. I will start a thread on it. I've got some ideas based around ceph-tools and mount-osds script.

[leseb]

@hookenz what does not work with ceph-disk? I've got it perfectly working with ceph/daemon, just as explained in #81. Oh ok I'll look at #98