On Fri, 10 Aug 2012, Sage Weil wrote: > On Fri, 10 Aug 2012, Danny Kukawka wrote: > > Am 10.08.2012 17:54, schrieb Sage Weil: > > > On Thu, 9 Aug 2012, Danny Kukawka wrote: > > >> Remove btrfs specific keys and replace them by more generic > > >> keys to be able to replace btrfs with e.g. xfs or ext4 easily. > > >> > > >> Add new key to define the osd fs type: 'fstype', which can get > > >> defined in the [osd] section for all OSDs. > > >> > > >> Replace: > > >> - 'btrfs devs' -> 'devs' > > >> - 'btrfs path' -> 'fs path' > > >> - 'btrfs options' -> 'fs options' > > >> - mkcephfs: replace --mkbtrfs with --mkfs > > >> - init-ceph: replace --btrfs with --fsmount, --nobtrfs > > >> with --nofsmount, --btrfsumount with --fsumount > > >> > > >> Update documentation, manpage and example config files. > > > > > > Maybe this should keep the old options as well, so that --mkbtrfs is an > > > alias for --mkfs --btrfs... > > > > I can add this to the patch, no problem! > > > > > Tommi, is this kind of invocation compatible with your notion of what > > > mkcephfs 2.0 should be? If we can jump to the target interface and > > > rewrite the implementation in terms of the new tools that would capture > > > the best of both worlds. > > > > If you can point me to some documentation how the target interface > > works, I could take a look at adapting mkcephfs to the new tools as soon > > as the new interface/workflow is ready. > > It's not defined yet. I know Tommi has something in his head, but I'm not > sure if it's something similar to the current one (a cluster-wide > ceph.conf) or something else. He's off today, so we probably have to wait > to find out.
Okay, I just synced up with Tommi. The goal is for the new 'mkcephfs' functionality to generalize to both cluster setup and expansion, and to avoid the pain associated with explicitly defining osd ids, paths, and devices for each osd. (IDs will by dynamic, hotplugging will be possible, etc.). The result will be the ability to define a file specifying information like - hosts that will be monitors, osds, and/or mons - config options to put in the ceph.conf, or config file fragment To instantiate osds, you could either: - explicitly run ceph-disk-prepare on the appropriate nodes, devices (specifying fs type etc) - plug in a properly tagged disk that will be magically consumed - possibly provide a list of devices/paths in the file above and let the mkcephfs replacement run it. Point being, it won't be a drop-in replacement for mkcephfs (with a ceph.conf as input) because the current approach makes you allocate osd ids and such, and the new approach won't require that. That being the case, I'm all for generalizing the current mkcephfs to other file systems as an interim step. I think the requirements there are just that the old options continue to work, and pick good names. That is, * conf: make 'btrfs ...' options alias to new options * mkcephfs: make --mkbtrfs an alias for '--mkfs' (or --mkosdfs?) * init-ceph: make the --btrfs alias --fsmount, etc. As for the new options, I suggest: * osd fs type * osd fs devs (will work for mkcephfs, not for new stuff) * osd fs path * osd fs options The new stuff can definitely use 'osd fs type' and 'osd fs option' (e.g., in [osd] section). It's less clear whether the others will remain useful, since they are generally tied to specific osd instances, which live in [osd.$id] sections, which the new stuff is won't require of you. My hope is for the both methods to be present in bobtail, and mkcephfs to be deprecated by cuttlefish. Does that sound reasonable? Thanks! sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
