On Wed, Jun 12, 2013 at 9:40 AM, Scottix <scottix@xxxxxxxxx> wrote: > Hi John, > That makes sense it affects the ceph cluster map, but it actually does a > little more like partitioning drives and setting up other parameters and > even starts the service. So the part I see is a little confusing is that I > have to configure the ceph.conf file on top of using ceph-deploy so it > starts to feel like double work and potential for error if you get mixed up > or you were expecting one thing and ceph-deploy does another. > I think I can figure out a best practice, but I think it is worth noting > that just running the commands will get it up and running but it is probably > best to edit the config file as well. I like the new ceph-deploy commands > definitely makes things more manageable. > A single page example for install and setup would be highly appreciated, > especially for new users. > > I must have skimmed that section in the runtime-changes thanks for pointing > me to the page. Just as a little more context, ceph-deploy is trying to provide a reference for how we expect users to manage ceph when using a configuration management system like Chef. Rather than trying to maintain a canonical ceph.conf (because let's be clear, there is no canonical one as far as Ceph is concerned), each host gets the information it needs in its ceph.conf, and the cluster is put together dynamically based on who's talking to the monitors. The reason you aren't seeing individual OSD entries in any of the configuration files is because the OSDs on a host are actually defined by the presence of OSD stores in /var/lib/ceph/osd-*. Those daemons should be activated automatically thanks to the magic of udev and our init scripts whenever you reboot, plug in a drive which stores an OSD, etc. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |