>>> Using Ceph on any decent scale actually requires one to use at least >>> Puppet >>> or similar tool, I wouldn't add any unnecessary complexity to already >>> complex code just because of novice users that are going to have hard >>> time >>> using Ceph anyway once a disk breaks and needs to be replaced, or when >>> performance goes to hell because users are free to create and remove >>> snapshots every 5 minutes. This discussion reminds me of a heated debate we had in the early days about whether configuration management should handle the provisioning of OSDs, or whether Ceph should have a tool to hide the ugliness. At the time, I was staunchly on the configuration management side. We used this horribleness to create new OSDs: https://github.com/dreamhost-cookbooks/ceph/blob/de5929eb45bda50785aa01181b281e25af0d1785/recipes/osd.rb Today we have ceph-disk (and soon to be ceph-volume)! I still have my reservations about the level of udev wizardry, which is tricky to debug, but it generally works and makes the experience better the vast majority of operators, reglardless . This lead to a single method to prepare OSDs that was configuration management agnostic. Nowadays all the Ansible/Chef/Puppet thingers use ceph-disk. -- 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
