We're having a chat about ceph-deploy tomorrow. We need to strike a balance between its being a useful tool for standing up a quick cluster and its ignoring the UNIX philosophy and trying to do to much. My assumption is that for most production operations, or at the point where people decide to invest in Ceph, users will already have selected a parallel execution and/or configuration management tool. Ensuring new or early PoC adopters, who perhaps don't want to wade into the wider-operational frameworks issues, is probably where the tool is best focused. Neil On Tue, Jan 22, 2013 at 3:57 PM, Travis Rhoden <trhoden@xxxxxxxxx> wrote: > On Tue, Jan 22, 2013 at 6:14 PM, Sage Weil <sage@xxxxxxxxxxx> wrote: >> On Tue, 22 Jan 2013, Neil Levine wrote: >>> Out of interest, would people prefer that the Ceph deployment script >>> didn't try to handle server-server file copy and just did the local >>> setup only, or is it useful that it tries to be a mini-config >>> management tool at the same time? >> >> BTW, you can also run mkcephfs that way; the man page will let you run >> individual steps and do the remote execution parts yourself. >> >> But I'm also curious what people think of the 'normal' usage... anyone? >> >> sage >> > > While I am interested to see where ceph-deploy goes, I do think > mkcephfs in its current form is quite useful. It does allow you to > stand up decent size clusters with relative ease and is fairly fast. > It has also come quite a ways since since the pre-argonaut form -- the > recent --mkfs additions coupled with the auto-mounting in > /etc/init.d/ceph is pretty slick. It was a nice discovery for me last > week, as I hadn't created a cluster from scratch since 0.50 or so. > > - Travis -- 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
