Hi Florian, New efforts should be directed to https://github.com/stackforge/puppet-ceph (mirrored at https://github.com/ceph/puppet-ceph) and evolving at https://review.openstack.org/#/q/status:open+project:stackforge/puppet-ceph,n,z I'm happily developing it with Andrew Woodward and David Simard and quite happy about how its future looks like. It will eventually unite all other modules and benefit from a proper integration test environment. I've been distressed far too often by the lack of integration tests when writing puppet modules. It makes all the difference in the world to me, although it's not currently popular among puppet module developers, to the point that the official tool (beaker) can't allocate a disk when creating an instance (!). I wrote a tiny tool https://pypi.python.org/pypi/gerritexec to listen to gerrit events, a simple one liner that actually runs the puppet modules for osd/mon on cuttlefish/dumpling/emperor in various situations. When working on puppet-ceph, my efforts are often directed to patching Ceph itself to make it more amicable to configuration management systems. "ceph-disk: prepare should be idempotent" is one example at http://tracker.ceph.com/issues/7475. But you will find a number of patches in Firefly oriented toward this goal. I believe this will also help reduce the complexity of the Chef, Ansible, Salt, ... playcookbooks (;-), in the same way hiding osd ids from them resolved a number of unnecessary problems for all of them (although some of them did not evolve to take advantage of it and are still overcomplex). From the point of view of someone in a hurry and no time to develop, what I'm doing it not useable at the moment. I'm under no pressure to rush anything and won't commit to any deadline ;-) However, if a developer is willing to help out, I'd be happy to spare the time to get her/him on board and speed up the process. Cheers On 10/03/2014 17:21, Florian Haas wrote: > Hi, > > Somehow I'm thinking I'm opening a can of worms, but here it goes > anyway. I saw some discussion about this here on this list last > (Northern Hemisphere) autumn, but not much since. > > I'd like to ask for some clarification on the current state of the > Ceph Puppet modules. Currently there are several: one on StackForge > (http://git.openstack.org/cgit/stackforge/puppet-ceph/), primarily > written by Loïc Dachary, and one on the eNovance GitHub repo > (https://github.com/enovance/puppet-ceph), written by Sébastien Han > and François Charlier. The eNovance repo is AGPL licensed, which I > find rather incomprehensible — the only thing this would make sense > for would be to force providers of *public* Puppet hosts to contribute > back upstream, but that's a really far fetched use case. The > StackForge repo is ASL licensed, which looks a bit saner. > > Then there is a TelekomCloud fork of the eNovance repo at > https://github.com/TelekomCloud/puppet-ceph/tree/rc/eisbrecher, with > 55 unmerged patches. Also AGPL, as far as I can tell. > > And finally there's puppet-cephdeploy > (https://github.com/dontalton/puppet-cephdeploy) where I like that it > builds upon ceph-deploy, but rather dislike that it's rather closely > interwoven with OpenStack. ASL. > > Finally, after the discussion that Loïc kicked off in > https://www.mail-archive.com/ceph-devel@xxxxxxxxxxxxxxx/msg16673.html, > there's https://github.com/ceph/puppet-ceph which hasn't seen any > updates in 2 months. This is a mirror of the StackForge module, as far > as I can tell, is ASL licensed and has seen neither the eNovance work > nor the TelekomCloud updates, presumably on account of the license > issue. > > Neither repo seems to be universally accepted and fully complete > (StackForge only supports mon deployment; eNovance doesn't do radosgw, > for example), so I'm trying to understand where people should best > direct their efforts to get things to a working state. > > All thoughts and comments appreciated. Thanks! > > Cheers, > Florian > -- > 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 > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
