On 08/10/2013 16:20, Don Talton (dotalton) wrote:> Hi Loic, > > We utilize stackforge's puppet modules to do our heavy lifting, including p-openstack, p-cinder, p-glance. There are dependency chains so that services will be restarted after configuration changes are made. Since many of our customers don't allow their baremetal nodes Internet access, we've added the packages to our APT repo to avoid the version issues with using either stock or public packages. > > You can probably find some other useful code the https://github.com/CiscoSystems/ repo, including what is needed to cohabitate MON/OSD nodes with OpenStack service nodes (https://github.com/CiscoSystems/puppet-coe/tree/grizzly/manifests/ceph) and more. The primary orchestration is in grizzly-manifests. You can see HOWTOs for different deployment scenarios here: http://docwiki.cisco.com/wiki/OpenStack:Ceph-COI-Installation. > > Hope this helps some! It does and it's great that all this is documented :-) Although there are a few modules around, re-using ceph-deploy seems to be the preferred method. I wonder what Alfredo would suggest. From a previous discussion we had I think he will suggest to use ceph-disk directly + cli / rest call instead. Looking at https://github.com/ceph/ceph-deploy/blob/master/ceph_deploy/new.py https://github.com/ceph/ceph-deploy/blob/master/ceph_deploy/mon.py etc. the layer provided by ceph-deploy is indeed thin. But is it something that needs to be duplicated in a puppet module ? Cheers -- Loïc Dachary, Artisan Logiciel Libre All that is necessary for the triumph of evil is that good people do nothing.
Attachment:
signature.asc
Description: OpenPGP digital signature
