I would suggest that it is always dangerous to make assumptions. If ceph-deploy needs some information, then this should be explicit, and configurable. If it needs to know whether initialisation is done by systemd, upstart, or sysv init, then what is wrong with requesting a config option? As it happens, ceph-deploy doesn't seem to be what I require as a mkcephfs replacement. An earlier exchange with Mark suggests that it wants to involve itself with the installation of software, and the configuration of startup mechanisms. This is not what I want, and it is not any part of what mkcephfs did. Given that I have ceph installed, and a bunch of disk drives, I need to be able to drive the ceph applications appropriately to set up the osd's, keys, and other required data so that I can start the ceph-osd(s), the ceph-mon(s), and the ceph-mds(s) [which I can do by typing! (and I can make systemd do it automatically if and when I find that I'm ready for that)]. This is what mkcephfs did. The original documentation site gave information on how to perform all these operations manually. I am not sure that this information is still available. Whilst I can see that a kind of 'Windows installer' type of application could be useful in some circumstances, it is not appropriate to delete basic instructions and believe that what I referred to as a 'smoke and mirrors' approach to operation is an adequate substitute. There has been several helpful replies here, and I thank those people. Please don't maintain the notion that some 'magic installer' is a proper substitute for basic and comprehensive 'man pages' and other appropriate documentation. I have been tracking ceph development for many tens of revisions; I have discovered the weakness of BTRFS for ceph (which I use in all cases except for OSDs, where I take the advice and use XFS); I experiment with different hardware configurations; I take advantage of all kernel developments that improve disk I/O performance; I keep working with the latest kernel and the latest ceph. I am really looking forward to being able to rely on ceph, it is the answer to many prayers. My test is to rsync a large amount of data (several terabytes) to a ceph filesystem and for this to happen without hitch. When this happens, I'll have confidence. Ceph stresses everything. I think that this day is now very close. Very warm regards, David On 13/11/2013 03:54, Mark Kirkwood wrote: > On 13/11/13 16:33, Mark Kirkwood wrote: >> On 13/11/13 04:53, Alfredo Deza wrote: >>> On Mon, Nov 11, 2013 at 12:51 PM, Dave (Bob) >>> <dave@xxxxxxxxxxxxxxxxxx> wrote: >>> >>>> It is unuseable for me at present, because it reports: >>>> >>>> [ceph_deploy][ERROR ] UnsupportedPlatform: Platform is not supported: >>>> >>> That looks like a bug. For the past few months the log output of >>> ceph-deploy has tried to improve to give as much useful information >>> as possible. >>> >>> To get to the bottom of this it would be super helpful to know what >>> distro you were attempting to connect to, what the actual command was, >>> and what version of ceph-deploy you were using. >>> >>> Hopefully, with that information and the (possible) bug fix, it will >>> mean that more and more people find ceph-deploy as a robust solution >>> to get >>> a Ceph cluster up and running. >>> >>> >> >> I believe he is using a self built (or heavily customized) Linux >> installation - so distribution detection is not going to work in this >> case. I'm wondering if there could be some sensible fall back for >> that, e.g: >> >> - refuse to install or purge >> - assume sysv init >> >> so that ceph-deploy can 'do the best it can' in these situations. >> Thoughts? >> > > Ahem - replying to myself, sorry: > > It might be just as easy to allow init to be specified as an option > (--init INITTYPE). As an aside, for my development (Ubuntu) > workstation, I'm building ceph from src and using ceph-deploy to > install it - *but* am switching init to sysv afterwards (I just prefer > to use it for that situation). > > Cheers > > Mark > > -- 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
